| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Also extend the test suite with more tests of inlined constructs
in object sets.
|
|
|
|
The smp1/1 test case seems test how well the SMP emulator can
parallelize tasks, not any functionality in the asn1 application
that is not tested in other tests.
|
|
|
|
|
|
* bjorn/asn1/not-small-bugs/OTP-11153:
PER/UPER: Correct decoding of SEQUENCEs with more than 64 extensions
testConstraints: Improve tests of semi-constrained INTEGERs
Test ENUMERATED with many extended values
UPER: Correct encoding of ENUMERATED with more than 63 extended values
Add asn1_test_lib:hex_to_bin/1
|
|
|
|
Make sure that semi-constrained integers are correctly encoded
in the mininum number of bytes. (The roundtrip test does not
catch problems with non-minimal encodings.) Also test huge
values that must be encoded in 128 or 256 bytes.
|
|
|
|
When a SEQUENCE was defined inline inside extension addition group
like this:
InlinedSeq ::= SEQUENCE {
...,
[[
s SEQUENCE {
a INTEGER,
b BOOLEAN
}
]]
}
the decoding code would return the contents of the SEQUENCE in a
record named 'InlinedSeq_ExtAddGroup1_s', while the record definition
in the generated HRL file would be 'InlinedSeq_s'.
Since there is no reason to use the longer record name (no risk for
ambiguity), correct the name in the decoding code.
|
|
|
|
|
|
|
|
|
|
|
|
Simplify the backends by letting asn1ct_check replacing a
with the actual type.
|
|
Given:
Semi ::= INTEGER (Lb..MAX, ...)
where Lb is an arbitrary integer, attempting to encode an
integer less than Lb would cause the encoder to enter an
infinite loop.
|
|
A semi-constrained INTEGER with a non-zero lower bound would be
incorrectly decoded. This bug was introduced in R16.
|
|
While at it, also test more integer values.
|
|
|
|
For the PER backends, generate code for accessing deep table
constraints at compile-time in the same way as is done for BER.
While at it, remove the complicated indentation code.
Also modernize the test suite and add a test for a deeper nested
constraint.
|
|
|
|
Unify the code for checking an enumeration value named in a
DEFAULT and in an ENUMERATED value. There is no need to handle
those cases differently. That also will also make sure that
the following works:
E ::= ENUMERATED { x, ..., y }
e E ::= x
(Extensible ENUMERATEDs were not handled when defining values.)
Always generate an error when an unknown enumeration value is
given (used in a DEFAULT, a message would be printed, but the
compilation would succeed). Also make sure that we always include
the line number for the incorrect enumeration.
Write a new test case and remove the extremely rudimentary
value_bad_enum_test/1 test case.
|
|
|
|
The list of files to remove was obtained by running "ls -lut"
after running the test cases and comparing the atime for each
file with the start of the test run.
|
|
|
|
|
|
In the 64-bit run-time, there is about 40Mb in old code after
running the asn1 test suite. Since it is very easy to reclaim
that memory, let's do it. Also get rid of the unnecessary call
to code:soft_purge/1 just before loading the new code.
|
|
Eliminate use of line macros and asn1_wrapper.
|
|
|
|
For the example from X.691, make sure to test that our encoded
value is the same as given in X.691.
Run the test for BER, too.
|
|
Ensure that compilation errors of Erlang code gets printed.
If compilation of an ASN.1 specification goes wrong, print out
the filename of the offending specification. It can be seen
in the test case log, but because most test cases run in a
parallel group, the test case log is not available until all
test case in the group have finished.
|
|
|
|
The encoder wrongly assumed that a known multiplier string (such as
IA5String) encoded as exactly 16 bits did not need to be aligned to an
octet boundary. X.691 (07/2002) 27.5.7 says that it does. Since an
OCTET STRING encoded to 16 bits (two octets) should not be aligned to
an octet boundary, that means that asnct_imm:dec_string() needs an
additional parameter to determine whether a string of a given length
needs to be aligned.
Furthermore, there is another subtle rule difference: An OCTET STRING
which does not have fixed length is always aligned (in PER), but
a known multiplier string is aligned if its upper bound is greater
than or equal to 16.
In encoding, make sure that short known multiplier strings and
OCTET STRINGs with extensible sizes are not aligned when they are
below the appropriate limit.
|
|
Given the type:
S ::= IA5String (SIZE (5, ...))
attempting to encode (to PER/UPER) a string shorter than 5 characters
would fail. Similarly, attempting to decode such string in the BER
format would fail.
In the case of BER, we can do no range checks if the size constraint
is extensible.
|
|
Consider a type with a size constraint with an extension marker
such as:
S ::= OCTET STRING (SIZE (0..10, ...))
For a length outside the root range (e.g. 42), the PER/UPER encoder
will encode the length field in the same way as it would the type
INTEGER (0..MAX) (i.e., as semi-constrained whole number), while the
decoder would decode the length in the same way as length field
without any constraint.
Clearly, either the encoder or the decoder is wrong. But which one?
Dubuisson's [1] book (page 442) says that the length should be encoded
as a semi-constrained whole number if the length is outside the root
range.
The X.691 standard document [2] also says (e.g. in 15.11) that length
fields should be a semi-constrained number, but gives a reference
to section gives a reference to section 10.9, "General rules for encoding
a length determinant", and not to to 10.7, "Encoding of a
semi-constrained whole number".
Reading the standard that way should imply that a length outside the
root range should be encoded in the same way as an unconstrained
length, and that the decoder does the right thing.
Further support for that interpretation:
- Larmouth's book [3], page 303.
- The ASN.1 playground. [4]
References:
[1] http://www.oss.com/asn1/resources/books-whitepapers-pubs/dubuisson-asn1-book.PDF
[2] http://www.itu.int/ITU-T/studygroups/com17/languages/X.691-0207.pdf
[3] http://www.oss.com/asn1/resources/books-whitepapers-pubs/larmouth-asn1-book.pdf
[4] http://asn1-playground.oss.com
|
|
|
|
The compiler would crash when given code such as the following:
Type ::= INTEGER (lower<..<upper)
lower INTEGER ::= 0
lower INTEGER ::= 42
|
|
The only code that is really different between the PER
and UPER backends is encoding of primitive types.
|
|
The wrong backend was used.
|
|
|
|
Optimize the decoding of CHOICE. Most important is to inline decoding
of the extension bit (if present) and decoding of the choice index
to give the BEAM compiler more opportunities for optimization.
We will also change the structure of the generated code. The current
code uses a flattened case for both the root and extension alternatives:
case Choice + NumRootChoices * Ext of
%% Root alternatives.
0 - ...;
:
LastRootAlternative -> ...;
%% Extension alternatives.
LastRootAlternative+1 -> ...;
:
%% Unknown extension.
_ -> ...;
end
We will instead generate nested cases:
case Ext of
0 ->
case Choice of
%% Root alternatives.
0 - ...;
:
LastRootAlternative -> ...
end;
1 ->
%% Extension alternatives.
<Decode the open type here>
case Choice of
0 -> ...;
:
LastExtensionAlternative -> ...;
%% Unknown extension.
_ -> ...;
end
end
Nested cases should be slightly faster. For decoding of the extensions,
it also makes it possible to hoist the decoding of the open type up
from each case to before the case switching on the extension index,
thus reducing the size of the generated code.
We will also do another change to the structure. Currently, the
big flat clase is wrapped in code that repackages the return values:
{Alt,{Value,RemainingEncodedData}} =
case Choice + NumRootChoices * Ext of
:
end,
{{Value,Alt},RemainingEncodedData}.
We still need to do the repackaging, but we can push it down to
the case arm for decoding each alternative. In many cases, that
will give the BEAM compiler the opportunity to avoid building the
temporary tuples.
|
|
* maint-r16:
Prepare release
Prepare release
Do not count offline run-queues as empty
Prepare release
Prevent loss of objects after the extension marker
Don't lose the extension mark for object set parameters
Conflicts:
erts/vsn.mk
|
|
* bjorn/asn1/fix-lost-extension-mark/OTP-10995:
Prevent loss of objects after the extension marker
Don't lose the extension mark for object set parameters
|
|
In an object set with a single root object, objects after
the extension marker would be lost.
|
|
When an object set is an actual parameter, the extension marker
for the object set could get lost.
|
|
Characters encoded in latin1 (with no encoding comment) will not
work in R17 since the default encoding will be UTF-8.
The asn1 test suite contains two instances of comments written in
Swedish.
The comment in the .asn1config file is hard to understand and possibly
out-of-date. Since the comment is not essential, simply delete it.
Translate the comment in the other file to English.
|
|
If the encoding is empty (i.e. if a top-level type is single-valued
and therefore not encoding), the result should be a single zero
byte.
|
