asn1 uper en/decoding of constrained numbers

[Vincent de Phily]

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


________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

[Kenneth Lundin]

Tanks for the report, I will take a look at this.

/Regards Kenneth Erlang/OTP, Ericsson

On Fri, Aug 20, 2010 at 1:36 PM, Vincent de Phily
<[hidden email]> wrote:

> 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
>
>
> ________________________________________________________________
> erlang-bugs (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:[hidden email]
>

________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]