Hi Max, On Mon, Apr 11, 2016 at 07:28:20PM +0200, Sylvain Munaut wrote:
Why would you put the conv code struct in the .h ?
I have to agree with Sylvain here, and fail to see the reason for the above design decisions. Particularly in a shared library like libosmocore/libosmogsm, the definition of the data should be in a C file that is actually shared read-only text to all its users, while the header files only contain forward declarations.
And why expose the tables in the public symbols ?
Indeed let's try to avoid this if possible.
The fact you can 'reuse' the tables in the test is really no reason to pollute the API namespace.
If I understand the code corectly, users would interact with it by means of the 'struct osmo_conv_code'. So that one would have to be declared in a header file, like: extern const struct osmo_conv_code osmo_conv_gsm0503_xcch; This kind of symbol would have to be exported in the .map file for actual consumption by the users of the library. which is then subsequently defined in a C file: const struct osmo_conv_code osmo_conv_gsm0503_xcch = { ... } But why would those declaraions below be in a header file? Why are those relevant to the user? +extern const uint8_t osmo_conv_gsm0503_xcch_output[][2]; +extern const uint8_t osmo_conv_gsm0503_xcch_state[][2]; Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)