asn1 uper en/decoding of constrained numbers
Vincent de Phily
<>
Fri Aug 20 13:36:29 CEST 2010
asn1rt_uper_bin:num_bits/1 can give wrong results for values above 1024. To be
precice, all values matching (2^N + 1) when N >= 10 give a result that is too
low by 1.
The end result is that for example this asn1 grammar:
MyInt11 ::= INTEGER(0..1024)
will be encoded (and decoded) using 10 bits instead of 11, and the encoded
value "1024" will be decoded as "0".
The least-disruptive fix is to change the last clause of num_bits/1 like this:
num_bits(R) ->
1+num_bits((R+1) bsr 1).
But I find the logic a bit obscure. Here's one that I find more readable
(YMMV), and is also faster for big numbers (slower for small ones) :
num_bits(N) -> num_bits(N, 1, 0).
num_bits(N, T, B) when N =< T -> B;
num_bits(N, T, B) -> num_bits(N, T bsl 1, B + 1).
Of course, ideally num_bits/1 should only be called at compiletime, not
runtime as is currently the case, so that execution speed does not matter :p
Sorry for not providing a proper patch and a place to pull from, but time to
do this always get preempted by more important stuff, and this is such a
simple bug that I think an email would suffice.
Cheers.
--
Vincent de Phily
-------------- next part --------------
A non-text attachment was scrubbed...
Name: num_bits.es
Type: application/ecmascript
Size: 1128 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20100820/8d149758/attachment.bin>
More information about the erlang-bugs
mailing list