Custom types about asn1scc HOT 1 CLOSED

Hi Iulian.

Unfortunately it's not as easy as it seems. The run-time library (RTL) code has been implemented using this as a basis - that integers are mapped in a "large enough" form for pretty much all actions. If we had chosen to be more optimal in mapping INTEGER declarations to the "smallest C integer type that can accommodate them", then the interaction between RTL functions would be more complex - especially in light of code that is safety critical and must pass through compilations and static analysis tools without any warnings (encoding functions like those in asn1crt.c would have to be declared for each target "zone" - and the proper ones selected during code generation, etc). This is all the more important for SPARK/Ada outputs, where the interaction between different "bit-width" values would make things even more complex.

In the end, as with all things, this is a balancing act - the decision to use a common representation makes things much simpler to reason about. And for the uses targeted by ASN1SCC, what matters is the result of encoding (that ends up transmitted across communication lines) - where indeed, ranges are taken very much into account: an INTEGER(0..15) will only need 4 bits "on the wire" in UPER encodings, etc.

from asn1scc.