9b54accd4d
The regular ASN.1 compiler does NOT sort SET { ... } types' members by
tag, though it should. It cannot because if a field is of an untagged
imported type, then the compiler won't know the field's tag because the
compiler does not read and parse IMPORTed modules. At least the regular
ASN.1 compiler does handle out-of-order encodings on decode.
The template ASN.1 compiler did not even support SET { ... } types at
all. With this commit the template ASN.1 compiler does, but still it
does not sort members on encode, and it does not decode out-of-
[definition-]order encodings.
A proper fix to these issues will require run-time sorting of SET
members on encode. An even better fix will require making the compiler
able to read and parse more than one module in one run, that way it can
know all the things about IMPORTed types that it currently leaves to
run-time.
16 lines
518 B
Groff
16 lines
518 B
Groff
-- $Id$ --
|
|
|
|
CANTHANDLE DEFINITIONS ::= BEGIN
|
|
|
|
-- Currently the compiler handles SET { ... } types, but does NOT sort
|
|
-- their members as should be done in the case of conforming DER encoders.
|
|
-- The workaround is to sort the members of such types manually in their
|
|
-- definitions. See X.690, section 10.3, and X.680, section 8.6 for details.
|
|
|
|
-- Can't handle primitives in SET OF, causing the compiler to crash
|
|
-- Workaround is to define a type that is only an integer and use that
|
|
|
|
Baz ::= SET OF INTEGER
|
|
|
|
END
|