Feature #3862
closedAdd support for asn1scc
0%
Description
The asn1c which we use is problematic due to non-existent maintenance: multiple forks implementing missing features, very infrequent releases, lots of distro-specific patches etc. As a result we even have to maintain our own fork of it.
There's alternative FOSS ASN.1 compiler which is under active development: https://github.com/ttsiodras/asn1scc
With documentation available from https://www.thanassis.space/asn1.html
It might be worth investigating whether it has the necessary features and could be used as a replacement of asn1c. The possible downside of missing distro packages could be greatly outweigh if we could drop maintenance burden induced by asn1c.
Related issues
Updated by msuraev about 5 years ago
- Related to Bug #2437: synchronize different asn1c APER forks added
Updated by msuraev about 5 years ago
- Related to Feature #2436: Test cases for asn1c APER encoding added
Updated by msuraev about 5 years ago
- Related to Bug #2435: Osmocom asn1c/libasn1c is based on old fork added
Updated by laforge about 5 years ago
- Status changed from New to Rejected
- Priority changed from Normal to Low
asn1scc doesn't support APER (aligned PER encoding), which is used on those interfaces/protocols where we currently use it. However, it supports UPER, from which it is typically not very hard to add APER support.
There are numerous other restrictions, which make it unsuitable for 3GPP protocols:
Asn1scc will not generate code for ASN.1 grammars that • contain SEQUENCE OFs and/or SET OFs with no SIZE constraint • contain OCTET STRINGs and/or BIT STRINGs with no SIZE constraint • IA5String, NumericString (and in general string types) with no SIZE constraint • Contain extendable CHOICEs, extendable SEQUENCES or extendable enumerations.
and, most importantly:
The current version of asn1scc is also not supporting some advanced ASN.1 features such as macros, parameterization and Information Class Objects.
For the time being, I think we're still best off with sticking to asn1c, possibly updatin to a more recent version like the one used by nextepc.
One other alternative we've been thinking about: Use proprietary ffasn1c (for which sysmocom has a license) while reimplementing the (currently proprietary) runtime library code as FOSS. ffasn1c could then run as a post-commit-hook on the git server, so if anyone ever pushes changes to the asn1 files, the C code is re-generated.