otp.git - Mirror of Erlang/OTP repository.

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 checking of object sets	Björn Gustavsson

2015-01-12	Remove special case in parser	Björn Gustavsson
	The parser handled the builtin ABSTRACT-SYNTAX and TYPE-IDENTIFIER classes specially, which caused problems. It turns out that there is no longer any need to handle those classes specially.
2014-09-01	Remove unused code for ABSTRACT-SYNTAX and TYPE-IDENTIFIER	Björn Gustavsson
	Before classes were fully implemented, there was support for ABSTRACT-SYNTAX and TYPE-IDENTIFIER. Some of that code is still there and is no longer used. Get rid of it and correct comments.
2014-09-01	Add the module name to the #classdef{} record	Björn Gustavsson
	If we want construct an #'Externaltypereference'{} from a #classdef{} record, we will need the module name.
2014-09-01	Eliminate the use of #identifier{} outside the tokeniser and parser	Björn Gustavsson
	The only remaining use of #identifier{} in asn1ct_check was in a temporary packaging of a value that would be ultimately be put into #valuedef{}. Therefore we can eliminate that last usage but putting the value directly into a #valuedef{} and we can move the record definition into asn1ct_parser2.
2014-09-01	Fix problem with object identifiers in external modules	Björn Gustavsson
	When parsing ASN.1, certain constructs can only be understood in the full context of the entire ASN.1 module. For instance, the value following ID in this simplified excerpt from MTSAbstractService88: administration-88 PORT ::= { ID {id-pt-administration 88} } the value following "ID" can be interpreted either as value for: SEQUENCE { id-pt-administration INTEGER } or as an OBJECT IDENTIFIER. Our ASN.1 parser assumes that a SEQUENCE is meant, and if that later turns out to be wrong, the SEQUENCE value is rewritten to an OBJECT IDENTIFIER. The problem is that at the time of the rewrite, we no longer know in which ASN.1 module id-pt-administration was defined in, and we have to use the module name in the state{} record. Unfortunately, the module name in the state{} record may not always be correct. While there are attempts in the code to keep the module name up-to-date when checking imported types, it is not done consistently, and it seems to be a difficult and error-prone task to attempt to make it consistent. A safer and less error-prone approach is to make sure that we don't lose the module name while parsing. To make it clear what we are doing, we will introduce a new #seqtag{} record that are used for tags in SEQUENCE values. The name is based on its primary use. The record also contains the module in case it happens to be an OBJECT IDENTIFIER.
2014-09-01	Teach the ASN.1 compiler to understand "EXPORTS ALL"	Björn Gustavsson
	EXPORTS ALL is the same as leaving out the EXPORTS statement.
2013-09-18	asn1ct_parser2: Clean the process dictionary after parsing	Björn Gustavsson
	Apart from cleanliness, the test suite runs many tests cases in parallel, so it never hurts to reduce the memory pressure.
2013-06-12	Update copyright years	Björn-Egil Dahlberg

2013-05-31	Eliminate use of #constraint{} outside of the parser	Björn Gustavsson
	The record #constraint{} is almost unused outside of the parser except for two places in asn1ct_check. The only correct usage of the record is in instance_of_constraints/2. Eliminate that usage by updating the parser to pass that constraint in the same way as all other constraints. In check_integer_range/2, the record is used incorrectly. A constraint for an integer will never be a list of #constraint{} records. Therefore, the list comprehension will always produce an empty list, and check_constr/2 will not actually check anything (which is kind of lucky, since the 'ValueRange' range constraint is incorrectly written - the lower and upper bounds should be in a tuple). For now, we will not attempt to actually start validating integer ranges. Firstly (obviously) we will need to be sure that we correctly handles all forms of constraints, and secondly we will need to consider whether we need to produce a warning rather than an error for compatibility reasons.
2013-05-31	Eliminate general use of #typereference{}	Björn Gustavsson
	The record #typereference{} is only used internally within the asn1ct_parser2 module (the parser translates it to an #'Externaltypereference{} record).
2012-12-18	asn1ct_parser2: Let synonyms share parsing code	Björn Gustavsson
	UNION and "\|" are synonyms, as are INTERSECTION and "^". Use the same parsing code for the synonyms.
2012-05-04	Add support for multiple ExtensionAdditionGroups	Kenneth Lundin

2012-02-28	[asn1] Make tables and processes unnamed	Adam Lindberg
	- Refactor and clean up asn1_db process - Remove unused stop function in asn1ct.erl - Remove infinite loop possibilites in asn1ct_check.erl - test/1,2,3 now run in separate process - Update documentation for new test options
2010-08-25	Add support for Extension addition group	Kenneth Lundin

2010-02-19	OTP-8463 Support for EXTENSIBILITY IMPLIED and SET/SEQ OF NamedType is	Kenneth Lundin
	added.
2009-11-20	The R13B03 release.OTP_R13B03	Erlang/OTP