11 Apr
2016
11 Apr
'16
6:21 p.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)