| Age | Commit message (Collapse) | Author |
|---|
|
* bjorn/asn1/fix-integer-constraint/OTP-11504:
PER/UPER: Handle a range in the extension part of the constraint
|
|
Constraints such as:
INTEGER (1..10, ..., 11..20)
would fail to compile. Make sure it is properly ignored.
|
|
* bjorn/asn1/fix-union-bug/OTP-11411:
Fix complicated union of INTEGER constraints
|
|
A constraint that was an union of integer ranges:
Type ::= INTEGER (lb1..ub1 | ... | lbN..ubN)
would sometimes (depending on the values) not all always be properly
combined to a single effective range, but would become:
Type ::= INTEGER (lb2..ub2) (lb3..ub3)
If that type was used in a SEQUENCE:
S ::= SEQUENCE {
v Type
}
the constraint would be simplified, taking the intersection of the
ranges.
|
|
An extensible constraint which is a union of single values, such as:
INTEGER (1|17, ...)
would be incorrectly encoded.
|
|
The asn1_wrapper made some sense when encode functions
could either produce a list or a binary, depending on the
backend. Now encode functions always produce a binary.
To improve readbility of the test suites, eliminate the asn1_wrapper
functions by replacing them with calls to one of the roundtrip
functions in asn1_test_lib. When it is not possible to use
the roundtrip functions, call the module in question directly.
While at it, also remove ?line macros that are near to the
touched code and use asn1_test_lib:hex_to_bin/1 instead of
home-brewn hex conversion routines.
|
|
Even if the roundtrip functions are very simply, putting them here
makes it possible to change its behavior in one place (e.g. if we
are to change encode and decode not to wrap the result in a ok tuple
in some future release).
|
|
|
|
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.
|
|
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.
|
|
|
|
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
|
|
|
|
|
|
* gustav/asn1/integer_single_value_predefined/OTP-10139:
In generation of encoding functions for enumeration types,
the values used for generating the range check in case of
a value range should be sorted and have duplicates removed.
Add sorting in constraint checking on single values.
Conflicts:
lib/asn1/test/testConstraints.erl
|
|
Fix a bug where a subtyped single value integer type where one or more values
were predefined would result in generated encoding code having faulty range
checks. See seq12102.
OTP-10139
|
|
Encoding and decoding of integer ranges can now be done
with an upper bound larger than the previous limit of 16^10.
The new upper bound in per encoding and decodings for constrained
whole numbers is 2^2040 (close to 16^508) which is the limit if
the length field encoding in the encoding of a constrained
whole number is limited to a single octet.
Related support seq: seq12060
|
|
|
|
|
|
* bg/asn1-tests:
asn1 tests: Let ts:run() build the tests
asn1 tests: No longer tolerate compilation warnings
asn1 tests: Eliminate use of deprecated concat_binary/1
asn1 tests: Eliminate warning for an unused variable
asn1 tests: Modernize guard tests
asn1 tests: Clean up comments
asn1 tests: Don't refer to $ERL_TOP in compiler options
OTP-8520 bg/asn1-tests
|
|
On Windows, $ERL_TOP contains a cygwin-style pathname
that can be used in Makefiles to (for instance) include
other Makefiles, but must not be passed to non-cygwin programs
such as "erlc". Therefore, using compiler options such as
"-I $(ERL_TOP)/lib/test_server/include" will not work on
Windows.
Fix this problem by include "test_server.hrl" using
-include_lib() instead of -include(). That works because
-include_lib() searches for include files in the code path
without the need for any -I options.
|
|
added.
|
