Hi Sylvain and Max,
On Wed, Apr 20, 2016 at 07:13:16AM +0200, Sylvain Munaut wrote:
src/gsm/conv_cs2_gen.c | 211 +++++++++++++++++++++++++++++
src/gsm/conv_cs3_gen.c | 299 ++++++++++++++++++++++++++++++++++++++++++
Why the _gen suffix ?
If they're fully automatically generated, then the build process
should generate them, they should not be in the repo at all.
As Max confirmed they're auto-generated, indeed it should be best to use
python to generate them during build. I don't mind a build dependency
on python. We cannot affor a runtime dependency on it, but that's not
the question here.
+extern const
struct osmo_conv_code osmo_conv_gsm0503_cs2;
+extern const struct osmo_conv_code osmo_conv_gsm0503_cs3;
Looking at all the other symbol in osmogsm, it seems we deemed 'osmo_'
to be redudant and so maybe "gsm0503_conv_cs2" would fit better in the
naming scheme ?
The problems with legacy namespace pollution ;) The general rule is
'anything we add should have an osmo_ prefix'. In some cases we might
deviate from this, e.g. if we simply add a function to an existing part
of the code. We don't have any gsm0503_ prefixed symbols so far, so I'm
more in favor of the 'general rule'. But I don't have strong feelings
about it, so let's probably keep it that way.
+static const
uint8_t osmo_conv_gsm0503_cs2_output[][2] = {
All those being purely internal symbols, then don't need osmo_conv
either
that's correct, so let's remove the prefix to avoid overly long lines.
--
- 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)