| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Fix recursion bug when decoding Constructed value within another
value - here the allowed buffer for the recursed decode shall
only be the size of the enclosing value, not the whole buffer.
Return ASN1_ERROR if BER decode recurses more than about 8 kWords.
|
|
|
|
|
|
|
|
The variable 'S' was used twice. If the test case failed
because there were unused functions in asn1_SUITE, there
would be an ugly badmatch exception instead of the intended
nice error message.
|
|
|
|
|
|
* hans/asn1/asn1ct_test_fix/ERL-518/OTP-14787:
asn1: asn1:test now handles no_ok_wrapper and undec_rest
|
|
|
|
|
|
|
|
* lars/doc-cleanup/OTP-14475:
[edoc] Remove unused module otpsgml_layout.erl
Remove unused files from the documentation build
|
|
|
|
|
|
|
|
|
|
* maint-20:
Updated OTP version
Prepare release
Accept non-binary options as socket-options
Bump version
Fix broken handling of default values in extensions for PER
compiler: Fix live regs update on allocate in validator
Take fail labels into account when determining liveness in block ops
Check for overflow when appending binaries, and error out with system_limit
|
|
|
|
|
|
Default values have never worked in extension for PER.
Note that for default values in the root part of SEQUENCE,
giving a value equal to the DEFAULT value, will result in
the same encoding as if asn1_DEFAULT was given. However,
that behavior is not promised by the documentation. The
documentation says that asn1_DEFAULT should be used for
default values. For DEFAULT in extensions, only implement
what the documentation promises and nothing more.
ERIERL-60
|
|
* maint-20:
Updated OTP version
Update release notes
Update version numbers
Fix doc for the 'quiet' option; it defaults to false
asn1: Fix missing quotes of external encoding call
Add a dedicated close function for TCP ports to prevent issues like ERL-430/448
Close TCP ports properly on send timeout
erts: Add missing release note
|
|
|
|
|
|
introduced by 8e4a9864385242b962ce7446f7daa4f58cfecca5.
|
|
EnumTypeName contains a hypen like fore example Cause-Misc. This caused
syntax errors when compiling the generated Erlang code.
|
|
|
|
|
|
|
|
This reverts commit eaf8ca41dfa4850437ad270d3897399c9358ced0.
|
|
|
|
This reverts commit dc57404252c47520f352834ad9be45ad684f96c9.
|
|
|
|
|
|
This is a poor man's solution that allows to build and test the
system with all files compiled to native code simply by setting
the ERL_COMPILER_OPTS environment variable. Better solutions,
like automatically setting the no_native option whenever the
compiler sees an on_load attribute, obviously exist but require
more time to implement.
|
|
Just crash if there is an internal error.
|
|
* Remove out-commented code
* Fix obvious typos and bad grammar
* Adhere to the conventions for when to use "%" and "%%".
|
|
Remove blank lines between clauses; use matching instead of
is_list/1 guards.
|
|
|
|
Stop up using asn1ct_gen:emit/1 with a tuple instead of a list.
Also remove the remaining uses of asn1ct_gen:demit/1.
|
|
The debug option no longer serves any useful purpose.
|
|
That will make code slightly easier to read.
|
|
The code is not covered. The code is also not present
in the PER backend.
Here is a somewhat more formal proof that the code cannot
be reached:
asn1ct_gen_ber_bin_v2:gen_encode_user/3 calls
asn1ct_gen:gen_encode_constructed/4 where Typename is a list
of one element.
asn1ct_gen:gen_encode_constructed/4 will call
asn1ct_gen_ber_bin_v2:gen_encode/3 via asn1ct_gen:gen_types/4.
Note that if InnerType in asn1ct_gen:gen_encode_constructed/4
is 'SEQUENCE OF' or 'SET OF', Typename will be extended to a
list with two elements.
If InnerType in asn1ct_gen:gen_encode_constructed/4 is
'SET', 'SEQUENCE', or 'CHOICE', then asn1ct_gen_ber_bin_v2:gen_encode/3
will be called with the last argument being a #'ComponentType'{}.
asn1ct_gen_ber_bin_v2:gen_encode/3 will in that cause extend
Typename before calling itself recursively.
Therefore, Typename is always a list with at least two elements
when the removed code is called.
|
|
ce431409d0daba broke generation of dialyzer suppressions
for per and uper.
While we are it, add type tests to asn1ct_func:is_used/1
to avoid similar problems in the future.
|
|
Tags number above 16383 were not decoded correctly in
ber_decode_tag().
We could fix the problem, but there does not seem to be any need.
First, the only way that high tag numbers can be created is with
manual tagging; after 1994 manual tagging is no longer recommended.
Second, the ASN.1 playground (http://asn1-playground.oss.com) only
supports tags up to 16383 (the same is presumably true for OSS
Nokalva's other tools).
Therefore, clean up the existing code and make it an explicit
'invalid_tag' error when tags above 13383 are encountered
(instead of an implicit 'wrong_tag' error).
|
|
|
|
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 an invalid value is encountered when trying to decode an
ENUMERATED, the exception can be quite verbose. Here is an actual
example from NBAP-PDU-Contents:
_ -> exit({error,{asn1,{decode_enumerated,{V4@V3,[chCode1div1,chCode2div1,chCode2div2,chCode4div1,chCode4div2,chCode4div3,chCode4div4,chCode8div1,chCode8div2,chCode8div3,chCode8div4,chCode8div5,chCode8div6,chCode8div7,chCode8div8,chCode16div1,chCode16div2,chCode16div3,chCode16div4,chCode16div5,chCode16div6,chCode16div7,chCode16div8,chCode16div9,chCode16div10,chCode16div11,chCode16div12,chCode16div13,chCode16div14,chCode16div15,chCode16div16]}}}})
Listing the possible values for an ENUMERATED when decoding fails is
not helpful and increases the code size (it would have made somewhat
more sense to list the possible values if *encoding* failed).
|
