| Age | Commit message (Collapse) | Author |
|---|
|
ASN.1: fix various problems with value definitions
OTP-15697
|
|
|
|
|
|
|
|
I did not find any legitimate use of "can not", however skipped
changing e.g RFCs archived in the source tree.
|
|
* maint-20:
Updated OTP version
Prepare release
Accept non-binary options as socket-options
Bump version
Fix broken handling of default values in extensions for PER
compiler: Fix live regs update on allocate in validator
Take fail labels into account when determining liveness in block ops
Check for overflow when appending binaries, and error out with system_limit
|
|
Default values have never worked in extension for PER.
Note that for default values in the root part of SEQUENCE,
giving a value equal to the DEFAULT value, will result in
the same encoding as if asn1_DEFAULT was given. However,
that behavior is not promised by the documentation. The
documentation says that asn1_DEFAULT should be used for
default values. For DEFAULT in extensions, only implement
what the documentation promises and nothing more.
ERIERL-60
|
|
* maint-20:
Updated OTP version
Update release notes
Update version numbers
Fix doc for the 'quiet' option; it defaults to false
asn1: Fix missing quotes of external encoding call
Add a dedicated close function for TCP ports to prevent issues like ERL-430/448
Close TCP ports properly on send timeout
erts: Add missing release note
|
|
introduced by 8e4a9864385242b962ce7446f7daa4f58cfecca5.
|
|
EnumTypeName contains a hypen like fore example Cause-Misc. This caused
syntax errors when compiling the generated Erlang code.
|
|
|
|
Tags number above 16383 were not decoded correctly in
ber_decode_tag().
We could fix the problem, but there does not seem to be any need.
First, the only way that high tag numbers can be created is with
manual tagging; after 1994 manual tagging is no longer recommended.
Second, the ASN.1 playground (http://asn1-playground.oss.com) only
supports tags up to 16383 (the same is presumably true for OSS
Nokalva's other tools).
Therefore, clean up the existing code and make it an explicit
'invalid_tag' error when tags above 13383 are encountered
(instead of an implicit 'wrong_tag' error).
|
|
|
|
Generate slightly better error reasons when encoding of INTEGER,
ENUMERATED, or BOOLEAN fails.
|
|
When the 'maps' option is given, the SEQUENCE and SET types are
represented as maps instead of as records. Optional and default values
must be not be given as asn1_NOVALUE or asn1_DEFAULT in a map passed
to the M:encode/2 function; they must be omitted from the
map. Similarly, when decoding missing values will be omitted from the
map.
No .hrl files will be generated when the 'maps' options is used.
That means values in an ASN.1 module must be retrieved by calling the
appropriate function in generated module.
Since we one day hope to get rid of the options 'compact_bit_string',
'legacy_bit_string', and 'legacy_erlang_types', we will not allow them
to be combined with the 'maps' option.
|
|
|
|
|
|
Remove the entire asn1rt module. All functions in it were deprecated in
OTP 17.
In asn1ct, remove the deprecated functions asn1ct:encode/3 and
asn1ct:decode/3. Also remove asn1ct:encode/2, which has not been
formally deprecated but is undocumented.
|
|
* henrik/update-copyrightyear:
update copyright-year
|
|
|
|
|
|
Cleanliness.
|
|
When a constrained INTEGER has more than 16536 values and named
values, the compiler would crash when compiling to the PER
format. Example:
Longitude ::= INTEGER {
oneMicrodegreeEast(10),
oneMicrodegreeWest(-10),
unavailable(1800000001)
} (-1799999999..1800000001)
Reported-by: Ingars
|
|
|
|
* 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.
|
|
|
