OSS/Nokalva

OSS/Nokalva's ASN.1 compiler can also be used by the Data Modeling toolchain. To that end, the ASN.1 grammar is automatically decorated during the system build process with the following OSS-specific directives:

• --<OSS.PDU>--
• --<OSS.ARRAY IA5String>--
• --<OSS.ARRAY BITSTRING>--
• --<OSS.ARRAY OCTETSTRING>--
• --<OSS.ARRAY SET OF>--
• --<OSS.ARRAY SEQUENCE OF>--

These directives instruct the OSS ASN.1 compiler to generate (to the extent it can) self-contained data structures that don't include pointers.

The code mappers, as discussed in section 11.2.1, include recursive descent mapping logic for both ASN1SCC and OSS/Nokalva. Comparing the implementations, it is clear that both tools try to mimic (to the extent possible) the original ASN.1 field and type declarations - they however diverge in some other aspects:

• OCTET STRINGs are represented as compound structures, with one field storing the length (nCount in ASN1SCC, length in OSS) and another field storing the data (arr and value respectively).
• Both tools use C unions to represent CHOICEs, and store the selected option via a C enumeration (named kind in ASN1SCC and choice in OSS). The enumerants are named whatever_PRESENT in ASN1SCC and OSS_whatever_chosen in OSS.
• SEQUENCEOFs are represented as C arrays (fields named arr and value respectively), and their length is stored in separate integer variables (nCount for ASN1SCC and count for OSS).

Overall, the impact of using another ASN.1 compiler is not as big as one would expect, since most of the mapping logic ends up being very similar. The APIs themselves (11.2.1 were also designed from the start to cope with this.