[PATCH 2/4] Add concolutional code generator for *CCH

[Harald Welte]

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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)