Attention is currently required from: pespin.
1 comment:
Patchset:
Let's see if we can all get on the same page here: my end objective in this patch series is to add some new functions to libosmocodec, and these functions happen to have this 06.31-defined ternary enum as their return value. Harald just said that naming ETSI-defined or 3GPP-defined things without osmo_ prefix is fine in <osmocom/gsm/protocol/xxx.h> headers - but if the present patch were to be accepted, then the very next patch in the series will have <osmocom/codec/codec.h> including the new <osmocom/gsm/protocol/gsm_06_31.h> header, in order to get that enum for the return value of osmo_{fr,efr}_sid_classify() functions. Thus if namespace pollution is a concern, then it does not stay confined to programs that explicitly include <osmocom/gsm/protocol/gsm_06_31.h>, instead everyone who includes <osmocom/codec/codec.h> will get it too.
So what should we do? Continue with the approach of creating this new <osmocom/gsm/protocol/gsm_06_31.h> header to hold the GSM 06.31 SID class enum, or go back to my original approach of putting this enum directly into <osmocom/codec/codec.h>? And as for the enum itself and its items, should I just bite the bullet and prefix them all with osmo_ even though they aren't Osmo-defined? If we decide the latter, I suggest this naming:
enum osmo_gsm631_sid_class
OSMO_GSM631_SID_CLASS_SPEECH
OSMO_GSM631_SID_CLASS_INVALID
OSMO_GSM631_SID_CLASS_VALID
Disadvantage: long. Advantage: achieves namespace containment while also making it clear that the definitions come from the spec and are not Osmocom-invented.
To view, visit change 32197. To unsubscribe, or for help writing mail filters, visit settings.