| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
An ENUMERATED with as single value is not encoded. The decoder
incorrectly assumed that it was encoded in one bit.
|
|
|
|
|
|
Some tests are are only run with BER backend. Unless there is a
special reason that the PER and UPER backends will not work, we
should run all tests with all backends to get the best possible
code coverage.
|
|
|
|
|
|
|
|
Commit f16f43446a04c459486356c0b4ad517cc9201895 broke compilation
of InformationFramework for per and uper.
|
|
Was broken in some backends in R15. Make sure that we will notice
if it breaks again.
|
|
On Windows, there is a limit to the number of characters in a
filename. Therefore, we don't want unnecessarily use any longer
path than necessary for case-specific directory. Since all test
cases that put anything into priv_dir is asn1_SUITE, it is not
necessary to include "asn1_SUITE" as part of the case-specific
directory.
|
|
All generated and compiled code are now put into separate sub
directories below priv_dir, so there is no point in adding
priv_dir to the code path.
|
|
|
|
* maint:
Prepare release
Don't run testX420/1 on old slow Sparc systems
testX420: Pass Options to the ASN.1 compiler
asn1_erl_nif: Correct broken length encoding
asn1_SUITE: Mend broken test_modified_x420/1
Revert "Prepare release"
Conflicts:
lib/asn1/doc/src/notes.xml
lib/asn1/test/asn1_SUITE.erl
|
|
* bjorn/asn1/open-type-error/OTP-10805:
asn1_erl_nif: Correct broken length encoding
asn1_SUITE: Mend broken test_modified_x420/1
|
|
* bjorn/asn1/extension-addition-groups/OTP-10811:
Fix a bug for multiple extension addition groups
|
|
One and a half hour is not enough for it to finish.
|
|
When the caller passed the 'der' option, it was ignored.
|
|
The test_modified_x420/1 test case had several problems that
prevented it to detect the bugs it was supposed to find:
1) There was a 'catch' at the top-level so that it could never fail.
2) There was a call to the now non-existing ssl_base64 module.
3) It did not test all options for the BER backend.
While at it, also clean way the remaining ?line macros and some
out-commented code.
|
|
|
|
Support in BER was removed in 3d1279f3cebfdd2483c3afea9f225613fe45cd00.
|
|
|
|
Add the option 'legacy_bit_string' to decode to the old list format.
|
|
There are two different definitions of the EXTERNAL data type in ASN.1:
the original from 1990 and an updated from 1994. Both defintions
are encoded in the same way (in BER). There are still
systems in use that use the old definition of EXTERNAL, so the
asn1 application must still support both.
It has been decided that the asn1 application should handle both
the forms without any compiler options. Internally the asn1 application
uses the 1990 definition. The encode functions will accept both
definitions, but translate the 1994 format to the 1990 format
if needed. When decoding, it will decode to the 1990 definition format
first and then translate to the 1994 defintion format.
One problem with this approach is that the conversion to the 1994
format may not be loss-less (where the 1990 defintion had a CHOICE
between an OPEN TYPE, OCTET STRING, or BIT STRING, the 1994 definition
only supports an OCTET STRING), and therefore it might not be possible
to correctly re-encode the data in the 1990 format.
It seems that the only reliable way to handle that problem is to not
do the conversion to the 1994 format if the conversion is not
loss-less. (There is an attempt when translating to the 1990 format
to recover the CHOICE alternative based on the Erlang type of
the data value, but that is neither reliable nor future-proof.)
That is, when decoding an EXTERNAL value, the resulting
tuple could either conform to the 1990 or 1994 definition, and
applications must be prepared to handle that.
The mail conversation where this issue was first reported can be
found here:
http://erlang.org/pipermail/erlang-questions/2011-April/057697.html
Reported-by: Harald Welte <[email protected]>
|
|
Always pre-encode the values for the enumeration. Clean up the
code and let the per and uper back-ends share the code.
|
|
enif_make_new_binary() cannot return NULL, so while at it,
remove the check for return value of enif_make_new_binary()
being NULL.
|
|
Also make sure that the error handling is contained within the
asn1rt_nif module and does not leak out to generated code.
|
|
|
|
|
|
The template modules (asn1rtt_*.erl) are based on the existing
run-time modules, but with some simplifications and improvements,
for example:
The run-time functions for BER encoding took a Constraint argument which
was not used. It has been eliminated, along with the unused StringType
argument for the encode_restricted_string function.
The Range argument for decode_enumerated() has been dropped since it
was not used.
|
|
|
|
* bjorn/asn1/extension-addition-groups/OTP-10664:
Fix a bug for multiple extension addition groups
|
|
Encoding would fail.
|
|
|
|
Support for the notation was removed in 6ef8cbdaaaa1c30a7dc462063.
|
|
The constraint simplification pass need to be seriously rethought
and rewritten.
As a starting point, add a test case to test that equivalent ways
to write a constraint are reduced to the same simplified constraint.
Fix a few obvious bugs to make the test cases to pass.
|
|
Extensions following a double bracket group were not skipped correctly.
Fix this bug and add tests to ensure that extensions are skipped
correctly.
|
|
|
