| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* maint:
asn1ct_gen: Correct generation of .hrl files for multiple ellipses
Fix BER code generation
|
|
|
|
PKIX1Explicit-2009 did not compile.
This commit was cherry-picked from 3ab3b07a already
merged into master.
|
|
|
|
Errors were reported using a throw like this:
throw({asn1_error,{get_line(hd(Tokens)),get(asn1_module),
[got,get_token(hd(Tokens)),expected,typereference]}}).
The attempt to tell the user what was expected was often mis-leading.
It is time-consuming and non-trival to provide correct information
of what is expected. Therefore, we will not even try. Instead we will
spend more effort to report the token where the error was discovered.
We will replace each throw with a function call:
parse_error(Tokens).
Also add the syntax_SUITE test suite to test error reporting and to
cover all error reporting code. Remove the old c_syntax/1 test case.
Also remove all out-commented code.
|
|
"SET OF id < Type" was not tested. Also make sure that all of
assigned values are correct.
|
|
Clean up the checking of ENUMERATED and modernize the error reporting.
Also eliminate the unused constraints argument for check_enumerated().
|
|
The ASN.1 compiler would go into an infinite loop if a value
in an ENUMERATED was negative.
|
|
|
|
Split the test case duplicate_tags/1 into two parts. Do the
error checking test in error_SUITE. Keep the SeqOptional2
specification and compile it from the per/1 and ber_other/1
test cases (for coverage).
|
|
|
|
The internal representation for constraints (and object sets)
as produced by the parser was awkward, making further processing
convoluted. Here follows some examples of the old representation
for INTEGER constraints.
The constraint 1..2 is represented as:
{'ValueRange',{1,2}}
If we extend the constraint like this:
1..2, ...,
or like this:
1..2, ..., 3
the representation would be:
{{'ValueRange',{1,2}},[]}
and
{{'ValueRange',{1,2}},{'SingleValue',3}}
respectively. Note that the pattern {A,B} will match all these
constraints.
When combining constraints using set operators:
1..2 | 3..4 ^ 5..6
the representation will no longer be a tuple but a list:
[{'ValueRange',{1..2}} union
{'ValueRange',{3..4}} intersection
{'ValueRange',{5..6}}]
The parse has full knowledge of the operator precedence; unfortunately,
the following pass (asn1ct_check) must also have the same knowledge
in order to correctly evaluate the constraints.
If we would change the order of the evaulation with round brackets:
(1..2 | 3..4) ^ 5..6
there would be a nested listed in the representation:
[[{'ValueRange',{1..2}} union {'ValueRange',{3..4}}]
intersection {'ValueRange',{5..6}}]
We will change the representation to make it more explicit.
At the outer level, a constraint is always represented as
{element_set,Root,Extension}
Extension will be 'none' if there is no extension, and 'empty' if
there is an empty extension. Root may also be 'empty' in an object set
if there are no objects in the root. Thus the constraints:
1..2
1..2, ...
1..2, ..., 3
will be represented as:
{element_set,{'ValueRange',{1,2}},none}
{element_set,{'ValueRange',{1,2}},empty}
{element_set,{'ValueRange',{1,2}},{'SingleValue',3}}
We will change the set operators too. This constraint:
1..2 | 3..4 ^ 5..6
will be represented as:
{element_set,
{union,
{'ValueRange',{1,2}},
{intersection,
{'ValueRange',{3,4}},
{'ValueRange',{5,6}}},
none}}
which is trivial to understand and evaluate. Similarly:
(1..2 | 3..4) ^ 5..6
will be represented as:
{element_set,
{intersection,
{union,{'ValueRange',{1,2}},{'ValueRange',{3,4}}},
{'ValueRange',{5,6}}},
none}
|
|
Changed the following from the original copies:
PKCS-5 (renamed from PKCS-v21)
PKCS-9 Import from CryptographicMessageSyntax-2009 instead
of CryptographicMessageSyntax
Since most of the files from the x420 directory are needed,
copy all of them into the rfcs directory and remove the
x420 directory and test case. Copy the test of OTP-7759 to
the testRfcs test case.
|
|
|
|
|
|
The ObjectSetFromObjects construct is implemented using
the object_set_from_objects() function, which is similar
to get_fieldname_element(). Rewrite the ObjectSetFromObjects
handling to use get_fieldname_element() to share more code.
|
|
|
|
a1260b2ffa60581ce3af0728320b593cca3fd7b0 fixed a problem with
expansion of parameterized types, but it didn't go all the way.
The compiler would still crash if we attempted to define a value
using the instantiated type.
|
|
|
|
|
|
To be sure that indirect references to classes are solved.
|
|
|
|
The parser handled the builtin ABSTRACT-SYNTAX and TYPE-IDENTIFIER
classes specially, which caused problems. It turns out that there
is no longer any need to handle those classes specially.
|
|
|
|
Add the ASN.1 specs from RFC-5911 and RFC-5912.
|
|
|
|
Besides simplifying the code and doing better error checking
and error reporting, fix the following bugs:
Support retrieving an OBJECT IDENTIFIER/RELATIVE-OID from an
object. Example:
oid OBJECT IDENTIFIER ::= some-object.&some-field
Allow an integer constant first in an OBJECT IDENTIFIER:
integer INTEGER ::= 0
oid OBJECT IDENTIFIER ::= {integer 1}
|
|
|
|
|
|
PKIX1Explicit-2009 did not compile.
|
|
Object sets with extension mark and without optional fields was not
generated properly. It needs the default [enc|dec]_xxx function clause
for the open type but no other clauses.
|
|
Rewrite the confusing and buggy matching of an object definition
against the simplified syntax.
While we are at it, we will also add proper error handling.
|
|
Refactor and clean up code. While at it, add error handling and
test cases. (Also add test cases for the existing values in
ValueTest.asn while we are it.)
Add support for defining INTEGER constants by extracting
fields from objects. Example:
int-from-object INTEGER ::= object.&id
When extracting values from objects in constraints, only one
level of extraction would work. That is, the following would
work:
SomeName ::= INTEGER (object.&int)
but not:
SomeName ::= INTEGER (object.&obj.&int)
|
|
There is duplicated effort in that validate_integer() checks
whether the integer value is valid, and then normalize_integer()
does mostly the same work in order to convert the value to an
integer.
Eliminate the validate_integer() function and incorporate
its checks into normalize_integer(). Also produce proper
error messages.
|
|
* dgud/asn1/fix-seqtag/OTP-12326:
asn1: Fix EXTERNAL (1994 variant) type conversion
|
|
Missed to add seqtag handling for EXTERNAL type conversion,
bug introduced in c266196c016fc1156c7a18cfeec4920ee4075519
|
|
|
|
According to the BER encoding rules, only constructed values may
have indefinite lengths. A primitive value must be encoded with
a definite length.
Reported-by: Simon Cornish
|
|
The following type of code would crash the compiler:
OSET SOME-CLASS ::= {OSET1, ..., OSET2}
|
|
Attempting to compile:
SomeType{SOME-CLASS-NAME, SOME-CLASS-NAME:SomeSet} ::= ...
SEQUENCE {
something SOME-CLASS-NAME.&id({SomeSet})
}
would crash the compiler, because the actual parameter for
SOME-CLASS-NAME was not substituted into the governor for
the SomeSet parameter.
While we are at it, combine the functionality of is_class/2
and get_class_def/2 (eliminating is_class/2). Most callers
call both function.
|
|
|
|
The code generator would crash.
|
|
|
|
If SetIn is defined like this:
SetIn ::= SET {
boolIn BOOLEAN,
intIn INTEGER
}
then it may not be used with an empty DEFAULT value like this:
SetDef1 ::= SET {
set1 SetIn DEFAULT {}
}
The ASN.1 compiler prints an warning message, but still generates
code. (That should be fixed.)
Fix the incorrect ASN.1 specification by making the
components in SetIn optional:
SetIn ::= SET
{
boolIn BOOLEAN OPTIONAL,
intIn INTEGER OPTIONAL
}
|
|
|
|
This will also eliminate a dialyzer warning for unmatched returns,
and increase the coverage.
|
|
Attempting to subtype an extensible ENUMERATED like this:
BaseType ::= { foo, bar, ... }
SubType ::= BaseType ( foo )
would fail to compile with a message that 'foo' was undefined.
Reported-by: Morten Nygaard Åsnes
|
|
|
|
|
