A new option has been introduced in ASN1C v6.5 for C/C++ that allows for the creation of more optimized structures for types containing size constraints. This is mostly true for items of fixed-size, for example OCTET STRING (SIZE (10)).
If this option is not used, the C structure generated is the standard C structure for OCTET STRING containing a numocts and data field:
struct {
OSUINT32 numocts;
OSOCTET data[10]
}
However, one might observe that the numocts field is not necessary in this case, the size should always be 10. In the early days of ASN.1 when only BER encoding existed, it was not uncommon for a user to interpret a constraint such as this as meaning a maximum size of 10 as opposed to a fixed size. This is similar to how one would interpret an array declared in a computer language as having a max size of 10. Hence the need to have a numocts (or other size field) to allow for the case when the field was not strictly interpreted to contain "10 and only 10" items.
With the advent of PER encoding, this lax interpretation was no longer possible as a size of 10 truly meant 10 only and length in the encoded data would be optimized away to take advantage of this fact. But the way ASN1C did code generation never evolved in the same way up until this release. Now, if -strict-size is added to the command-line, the generated structure will be as follows:
struct {
OSOCTET data[10];
}
The numocts field has been removed completely. A similar optimization has also been done in this case to use the smallest sized integer to hold the size value for a particular range. For example, if SIZE (1..10) is specified on a certain type, the compiler will use an 8-bit unsigned integer (unsigned char in C) as opposed to a standard 32 or 64 bit integer to hold the value.