Fix problem with object identifiers in external modules

When parsing ASN.1, certain constructs can only be understood in
the full context of the entire ASN.1 module.

For instance, the value following ID in this simplified excerpt
from MTSAbstractService88:

administration-88 PORT ::= {
  ID {id-pt-administration 88}
}

the value following "ID" can be interpreted either as value
for:

  SEQUENCE {
    id-pt-administration INTEGER
  }

or as an OBJECT IDENTIFIER.

Our ASN.1 parser assumes that a SEQUENCE is meant, and if that
later turns out to be wrong, the SEQUENCE value is rewritten to
an OBJECT IDENTIFIER. The problem is that at the time of the
rewrite, we no longer know in which ASN.1 module id-pt-administration
was defined in, and we have to use the module name in the state{}
record. Unfortunately, the module name in the state{} record may
not always be correct.

While there are attempts in the code to keep the module name
up-to-date when checking imported types, it is not done consistently,
and it seems to be a difficult and error-prone task to attempt
to make it consistent.

A safer and less error-prone approach is to make sure that we
don't lose the module name while parsing. To make it clear what
we are doing, we will introduce a new #seqtag{} record that
are used for tags in SEQUENCE values. The name is based on its
primary use. The record also contains the module in case it happens
to be an OBJECT IDENTIFIER.

0 files changed, 0 insertions, 0 deletions