| Oh, I agree. I don't like the printf/scanf-like approach to BER encoding. In fact, it's awful. The point I was making is that code generation is not the only option for ASN.1 or any encoding. Also, ASN.1 types map very well onto C (surprise): - OCTET STRING -> struct with pointer and length in bytes - BIT STRING -> struct with pointer and length in bits - INTEGER (constrained) -> some stdint.h integer type - INTEGER (unconstrained) -> struct with pointer to array of uint64_t, array element count, and boolean to indicate if signed or unsigned - REAL -> double or some arbitrary precision real library's type - most string types -> pointer to array of char, or counted byte string type - SEQUENCE OF and SET OF -> struct with pointer to array and count of elements - SEQUENCE and SET -> struct - CHOICE -> struct with discriminant enum and union of alternatives - tags -> ignore - OPTIONAL -> pointer - DEFAULT -> nothing special - NULL -> int (whatever) - BOOLEAN -> unsigned int, bool, maybe a bitfield of unsigned integer type so that all booleans can be compressed, etc. - OBJECT IDENTIFIER and RELATIVE OBJECT IDENTIFIER -> struct with pointer to DER encoding, and length in bytes - extensibility markers -> [hard to make this pithy, but it can be handled just fine] That covers like 99% of it. Suffice it to say that there's a very natural mapping of most of ASN.1 onto C. Things like classes and object sets aren't types but can guide the tooling to provide automatic encoding and decoding through open types (typed holes). BTW, `SET` is silly. `SET OF` is only of interest if you have arrays where order doesn't matter and you want a canonical encoding, but since one should not depend on canonical encodings, `SET OF` is also silly. IMO both should be deprecated (they can't be removed, but hey). |