| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Three fields ('type','value', and 'vname') are almost unused. They
are set, but almost never read. Eliminate the last remaining uses
and the fields themselves.
|
|
All errors were not reported. Furthermore, get_referenced_type/2
will report errors if any module is missing, so the attempt to
report additional errors in chained_import/4 would not find any
errors.
|
|
File names and line number information was not reliable available
when producing error messages. Some items have embedded line number
information, and sometimes the S#state.type and/or S#state.value
could be used to retrieve the line number information.
To make sure that we can always retrieve at least an approximate
error location, store the top-level construct being checked in
S#state.error_context. Example of top-level constructs:
Seq ::= SEQUENCE {...}
i INTEGER ::= 42
This is a short-term solution. In the long term, we would want the
parser to include line number information in all items.
|
|
If we want construct an #'Externaltypereference'{} from
a #classdef{} record, we will need the module name.
|
|
The only remaining use of #identifier{} in asn1ct_check was in a
temporary packaging of a value that would be ultimately be put
into #valuedef{}.
Therefore we can eliminate that last usage but putting the value
directly into a #valuedef{} and we can move the record definition
into asn1ct_parser2.
|
|
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.
|
|
The record #constraint{} is almost unused outside of the parser
except for two places in asn1ct_check.
The only correct usage of the record is in instance_of_constraints/2.
Eliminate that usage by updating the parser to pass that constraint
in the same way as all other constraints.
In check_integer_range/2, the record is used incorrectly. A
constraint for an integer will never be a list of #constraint{}
records. Therefore, the list comprehension will always produce
an empty list, and check_constr/2 will not actually check anything
(which is kind of lucky, since the 'ValueRange' range constraint
is incorrectly written - the lower and upper bounds should be in
a tuple).
For now, we will not attempt to actually start validating integer
ranges. Firstly (obviously) we will need to be sure that we
correctly handles all forms of constraints, and secondly we will
need to consider whether we need to produce a warning rather than an
error for compatibility reasons.
|
|
The record #typereference{} is only used internally within
the asn1ct_parser2 module (the parser translates it to
an #'Externaltypereference{} record).
|
|
|
|
|
|
|
|
|
