On Sun, 23 Mar 2025 14:08:29 +0100, Petter Reinholdtsen wrote: > [Jean Delvare] > > Your original reason for not going with a "static" set of function > > pointers but instead using a struct of them was that it would "allow > > for some extra flexibility". Could you elaborate on this? > > I must admit, I do no longer remember why I wrote this. > > Looking at the code, the advantage I see is that using a struct of > function pointers instead of direct references to functions make sure > all methods calls need to go through this defined interface, and that > new members can be appended to the struct in a later version without any > changes to precompiled library clients. It also allow changes to the > implementation of these methods (like inserting a new output format or > an alternative implementation for the same format) without rebuilding > the client, which can be selected by new logic in set_output_format() > without affecting shared library clients.
Library clients? Dmidecode is a standalone tool, there's no library involved. The alternative output format implementation is fully internal, so binary compatibility is not an issue. Nor compatibility at all, for that matter. Of course, if this was part of a library API, I would go with a struct without a doubt, and I'd consider adding some sort of validation too. -- Jean Delvare SUSE L3 Support
