aboutsummaryrefslogtreecommitdiffstats
path: root/lib/asn1/src/asn1rtt_per.erl
AgeCommit message (Collapse)Author
2016-03-15update copyright-yearHenrik Nord
2015-06-18Change license text to APLv2Bruce Yinhe
2013-08-30PER, UPER: Optimize encoding using an intermediate formatBjörn Gustavsson
There are some minor incompatibilities for BIT STRING: {bit,Position} is now only only supported for a named BIT STRING type. Values longer than the maximum size for the BIT STRING type would be truncated silently - they now cause an exception.
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: Remove support for a list argument for encode_open_type/1Björn Gustavsson
Almost always, encode_open_type/1 is called with the return value from complete/1, which always is a binary. In the rare situation that encode_open_type/1 is called directly with data from the user application, call iolist_to_binary/1 before calling encode_open_type/1.
2013-05-31Normalize SIZE constraints to simplify backendsBjörn Gustavsson
2013-05-31PER: Fix aligments bugs for short stringsBjörn Gustavsson
The encoder wrongly assumed that a known multiplier string (such as IA5String) encoded as exactly 16 bits did not need to be aligned to an octet boundary. X.691 (07/2002) 27.5.7 says that it does. Since an OCTET STRING encoded to 16 bits (two octets) should not be aligned to an octet boundary, that means that asnct_imm:dec_string() needs an additional parameter to determine whether a string of a given length needs to be aligned. Furthermore, there is another subtle rule difference: An OCTET STRING which does not have fixed length is always aligned (in PER), but a known multiplier string is aligned if its upper bound is greater than or equal to 16. In encoding, make sure that short known multiplier strings and OCTET STRINGs with extensible sizes are not aligned when they are below the appropriate limit.
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.
2013-05-31PER/UPER: Correct encoding of a length outside the root rangeBjörn Gustavsson
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
2013-05-31PER: Eliminate useless argument for encode_octet_string()Björn Gustavsson
For what seems to be historical reasons, asn1_rtt_per:encode_octet_string/3 has an ExtensionMarker argument that is no longer used. The extension mark (if any) is included in the constraints argument.
2013-05-31asn1_constructed_per: Optimize decoding of CHOICEBjörn Gustavsson
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.
2013-03-12PER: Ensure that the complete encoding is at least one byteBjörn Gustavsson
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.
2013-02-16Eliminate use of obsolete size/1 in generated codeBjörn Gustavsson
It is recommended to use byte_size/1 or tuple_size/1 instead of size/1.
2013-01-25Update copyright yearsBjörn-Egil Dahlberg
2013-01-23Simplify the functions for decoding lengthsBjörn Gustavsson
Now that the decoding of all types are generated inline, we can take out most of the code for decoding lengths.
2013-01-23per,uper: Optimize decoding of the remaining data typesBjörn Gustavsson
2013-01-23per,uper: Optimize decoding of the remaining string typesBjörn Gustavsson
2013-01-23per,uper: Optimize decoding of the string data typesBjörn Gustavsson
2013-01-22Teach encode functions to accept a bitstring term for a BIT STRINGBjörn Gustavsson
We do it in the simplest possible way by converting the bitstring to a compact bitstring tuple. The encoding of BIT STRINGs should be cleaned up and optimized.
2013-01-22Refactor decoding of BIT STRINGsBjörn Gustavsson
Refactor decoding of BIT STRINGs so that the run-time code does not spend testing conditions that are known already at compile-time (which wastes time and produces unnecessary Dialyzer warnings). There are three ways to decode BIT STRINGs: 1) To a list of bit names (and {bit,Position} for unnamed positions) if the BIT STRING type has any bit names. 2a) To a list of ones and zeros if there are no named bits, and the compact_bit_string option was NOT given. 2b) To a {Unused,Bin} tuple if there are no named bits compact_bit_string option WAS given. Structure the decoding functions in the same way.
2013-01-22Optimize encoding of ENUMERATED in per and uperBjörn Gustavsson
Always pre-encode the values for the enumeration. Clean up the code and let the per and uper back-ends share the code.
2013-01-22Correct error handling for the NIF functionsBjörn Gustavsson
Also make sure that the error handling is contained within the asn1rt_nif module and does not leak out to generated code.
2013-01-22Add run-time library templates and use themBjörn Gustavsson
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.