| Age | Commit message (Collapse) | Author | |
|---|---|---|---|
| 2015-01-12 | Rewrite constraint handling | Bjö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-12 | Clean up constraint checking | Björn Gustavsson | |
| 2015-01-12 | Refactor code involving calls to get_fieldname_element/3 | Bjö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 INTEGER | Björn Gustavsson | |
| 2014-06-05 | (U)PER: Fix encoding of a semi-constrained, named INTEGER | Björn Gustavsson | |
| The code generator would crash. | |||
| 2013-12-02 | Merge branch 'bjorn/asn1/fix-integer-constraint/OTP-11504' into maint | Björn Gustavsson | |
| * bjorn/asn1/fix-integer-constraint/OTP-11504: PER/UPER: Handle a range in the extension part of the constraint | |||
| 2013-11-29 | PER/UPER: Handle a range in the extension part of the constraint | Björn Gustavsson | |
| Constraints such as: INTEGER (1..10, ..., 11..20) would fail to compile. Make sure it is properly ignored. | |||
| 2013-11-20 | Merge branch 'bjorn/asn1/fix-union-bug/OTP-11411' into maint | Björn Gustavsson | |
| * bjorn/asn1/fix-union-bug/OTP-11411: Fix complicated union of INTEGER constraints | |||
| 2013-10-17 | Fix complicated union of INTEGER constraints | Bjö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-30 | PER/UPER: Correct encoding for single-value extensible constraints | Björn Gustavsson | |
| An extensible constraint which is a union of single values, such as: INTEGER (1|17, ...) would be incorrectly encoded. | |||
| 2013-05-31 | Fix encoding of semi-constrained, extensible INTEGERs | Bjö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-31 | PER/UPER: Fix decoding of semi-constrained INTEGERs | Björn Gustavsson | |
| A semi-constrained INTEGER with a non-zero lower bound would be incorrectly decoded. This bug was introduced in R16. | |||
| 2013-05-31 | Correct encoding (decoding) of lengths less than the root range | Bjö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-15 | Merge branch 'gustav/asn1/integer_single_value_predefined/OTP-10139' into maint | Gustav 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-05 | Add 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-28 | Add support for larger integer ranges in per encode/decode | Gustav 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-27 | Correct handling of INTEGER (1..4 | 8 | 10 | 20) | Kenneth Lundin | |
| 2010-02-19 | OTP-8463 Support for EXTENSIBILITY IMPLIED and SET/SEQ OF NamedType is | Kenneth Lundin | |
| added. | |||
 |
index : otp.git | |
| Mirror of Erlang/OTP repository. | OTP Team |
| aboutsummaryrefslogtreecommitdiffstats |