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
-------------- 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>