| Age | Commit message (Collapse) | Author |
|---|
|
The generated encode/2 and decode/2 functions can return
cryptic error messages. Consider this ASN.1 spec:
T DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
S ::= SEQUENCE {
b BOOLEAN,
i INTEGER (1..100),
j INTEGER (0..7),
s OCTET STRING
}
END
In OTP 19, the error terms will look like this:
Eshell V8.2 (abort with ^G)
1> asn1ct:compile('T', [ber]).
ok
2> rr('T').
['S']
3> 'T':encode('S', #'S'{}).
{error,{asn1,{encode_boolean,undefined}}}
4> 'T':encode('S', #'S'{b=false}).
{error,{asn1,{encode_integer,undefined}}}
5> 'T':encode('S', #'S'{b=false,i=7,j=0}).
{error,{asn1,function_clause}}
Some error terms are clearer than other. In the first error
term, it is clear that the error refers to the 'b' field,
since there is only one BOOLEAN in 'S'. The second error
term could refer to either 'i' or 'j'. The last error term...
well... in this case we can infer that it must refer to 's'.
The easiest way to provide more information is to include
the stack trace with line numbers in the error term:
3> 'T':encode('S', #'S'{b=false}).
{error,{asn1,{{encode_integer,undefined},
[{'T',encode_integer,2,[{file,"T.erl"},{line,240}]},
{'T',enc_S,2,[{file,"T.erl"},{line,102}]},
{'T',encode,2,[{file,"T.erl"},{line,36}]},
{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,674}]},
{shell,exprs,7,[{file,"shell.erl"},{line,686}]},
{shell,eval_exprs,7,[{file,"shell.erl"},{line,641}]},
{shell,eval_loop,3,[{file,"shell.erl"},{line,626}]}]}}}
By looking at the generated Erlang code, we can see that encoding
failed for 'i'.
This is an compatible change. All that the documentation says is
that the format of the error tuple is:
{error,{asn1,Description}}
With this change, Description is always a tuple:
{ErrorDescription,StackTrace}
Alternatives considered: Providing more information in the error
term itself and make sure there can be no 'function_clause', 'badarg',
or 'badmatch' exceptions. That would be possible, but it would
require a lot of work and it would increase the size of the generated
code and make it slower. Therefore, this solution was rejected.
|
|
When the 'maps' option is given, the SEQUENCE and SET types are
represented as maps instead of as records. Optional and default values
must be not be given as asn1_NOVALUE or asn1_DEFAULT in a map passed
to the M:encode/2 function; they must be omitted from the
map. Similarly, when decoding missing values will be omitted from the
map.
No .hrl files will be generated when the 'maps' options is used.
That means values in an ASN.1 module must be retrieved by calling the
appropriate function in generated module.
Since we one day hope to get rid of the options 'compact_bit_string',
'legacy_bit_string', and 'legacy_erlang_types', we will not allow them
to be combined with the 'maps' option.
|
|
Remove the entire asn1rt module. All functions in it were deprecated in
OTP 17.
In asn1ct, remove the deprecated functions asn1ct:encode/3 and
asn1ct:decode/3. Also remove asn1ct:encode/2, which has not been
formally deprecated but is undocumented.
|
|
|
|
Fix some older errors as well.
|
|
|
|
This reverts commit e020f75c10410a6943cd055bfa072a2641eab7da.
|
|
|
|
This reverts commit bd64ad8e15d66e48b36dbe3584315dd5cfc8b59a.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add a note about the limitations of the asn1ct:test/1,2,3 and
asn1ct:value/2 functions.
|
|
This reverts commit e09dd66dc4d89c62ddfd8c19791f9678d5d787c6.
|
|
|
|
There is now only one BER back-end, and there is no 'optimize'
option.
|
|
Language cleaned up by the technical writers xsipewe and tmanevik
from Combitech. Proofreading and corrections by Björn Gustavsson.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When talking about the ASN.1 standard, ASN.1 specifications, and
the ASN.1 compiler, consistently use "ASN.1" instead of "asn1".
|
|
|
|
The trailing bytes returned are now always a binary. Also condense
and clean up the language.
|
|
REAL is implemented, sort of. But real numbers must be given in
a string.
|
|
While "extendability" (without the hyphen) is an English word,
"extensibility" is the established term used when talking about
the extensibility of ASN.1 types.
|
|
The section about encoding rules serves no useful purpose. Most users
already know which encoding rule to use for their specifications. The
few users that have their own specification and need to decide on
which encoding rule to use will need much more information.
|
|
Since 1994 when the AUTOMATIC TAGS was introduced, ASN.1 users
no long need to worry about tagging, and the following sentence
no longer makes any sense:
It is essential for all users of ASN.1 to
understand all the details about tags.
Therefore, remove the entire existing section of tags, and replace
it with a shorter section explaining why we no longer need to know
about tags. Remove all tags from the examples.
|
|
Since the SET type is used exactly the same way as the SEQUENCE
type in Erlang, we can simply say so and note that decoding will
be less efficient for the BER and DER encoding rules.
|
|
It turns out that the current BER back-end can recognize complex
DEFAULT values, so I had to commit up with a more elaborate
example to show a difference between the BER and DER back-ends.
|
|
|
|
The decode functions now return a binary, not an iolist, so we must
both change the output and remove the call to list_to_binary when
decoding.
|
|
|
|
Replace "IMPLICIT TAGS" with "AUTOMATIC TAGS" since AUTOMATIC TAGS
is recommended for all new ASN.1 specifications.
|
|
We can assume that anyone that reads the documentation for the Asn1
documentation already knows about ASN.1, so we don't need three
paragraphs of introductory. Keep one short paragraph explaining
what ASN.1 is in case a reader unfamiliar with ASN.1 stumbles upon
the manual.
While we are at it, reformat the paragraphs in Introduction to
shorter lines that don't wrap.
|
|
|
|
|
|
|
|
|
|
The R16B03 release
Conflicts:
lib/sasl/vsn.mk
|
|
|
|
* maint:
Teach the ASN.1 compiler the no_ok_wrapper option
Optimize the generated decode/2 function
|
|
Add the no_ok_wrapper option so that the generated M:encode/2 and
M:decode/2 functions will not wrap a successful return value in an
{ok,...} tuple. Errors will cause exceptions.
Eliminating the wrapping tuple allows simpler nesting of calls.
|
|
The R16B02 release
Conflicts:
lib/sasl/vsn.mk
|
|
|
