aboutsummaryrefslogtreecommitdiffstats
path: root/lib/asn1/test/asn1_SUITE_data/Constraints.py
AgeCommit message (Collapse)Author
2015-01-12Rewrite constraint handlingBjörn Gustavsson
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}
2015-01-12Clean up constraint checkingBjörn Gustavsson
2015-01-12Refactor code involving calls to get_fieldname_element/3Björn Gustavsson
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)
2014-06-05(U)PER: Fix decoding of named INTEGERBjörn Gustavsson
2014-06-05(U)PER: Fix encoding of a semi-constrained, named INTEGERBjörn Gustavsson
The code generator would crash.
2013-12-02Merge branch 'bjorn/asn1/fix-integer-constraint/OTP-11504' into maintBjörn Gustavsson
* bjorn/asn1/fix-integer-constraint/OTP-11504: PER/UPER: Handle a range in the extension part of the constraint
2013-11-29PER/UPER: Handle a range in the extension part of the constraintBjörn Gustavsson
Constraints such as: INTEGER (1..10, ..., 11..20) would fail to compile. Make sure it is properly ignored.
2013-11-20Merge branch 'bjorn/asn1/fix-union-bug/OTP-11411' into maintBjörn Gustavsson
* bjorn/asn1/fix-union-bug/OTP-11411: Fix complicated union of INTEGER constraints
2013-10-17Fix complicated union of INTEGER constraintsBjörn Gustavsson
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.
2013-09-30PER/UPER: Correct encoding for single-value extensible constraintsBjörn Gustavsson
An extensible constraint which is a union of single values, such as: INTEGER (1|17, ...) would be incorrectly encoded.
2013-05-31Fix encoding of semi-constrained, extensible INTEGERsBjörn Gustavsson
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.
2013-05-31PER/UPER: Fix decoding of semi-constrained INTEGERsBjörn Gustavsson
A semi-constrained INTEGER with a non-zero lower bound would be incorrectly decoded. This bug was introduced in R16.
2013-05-31Correct encoding (decoding) of lengths less than the root rangeBjörn Gustavsson
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.
2012-08-15Merge branch 'gustav/asn1/integer_single_value_predefined/OTP-10139' into maintGustav Simonsson
* 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
2012-07-05Add sorting in constraint checking on single values.Gustav Simonsson
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
2012-06-28Add support for larger integer ranges in per encode/decodeGustav Simonsson
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
2012-03-27Correct handling of INTEGER (1..4 | 8 | 10 | 20)Kenneth Lundin
2010-02-19OTP-8463 Support for EXTENSIBILITY IMPLIED and SET/SEQ OF NamedType isKenneth Lundin
added.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-11 10:00:04 +0000