[coyotos-dev] BigNum.cxx buglet?

[Thomas Stratmann]

Hi everyone,

this is my first post here. Hello everybody! :-)

Jeroen Visser schrieb:
> My 'make' of Coyotos hangs in the 'capidl of Discrim.h'.
> 
> In particular capidl loops endlessly in BigNum.cxx line 260:
> 
>     ....
>     while (n3.len > n1.len) {
>       n3.vec[n3.len-1] = 0;
>     }
> 
> This looks like it might be a buglet.

I found the very same problem just a few days ago but found no time to 
fix this yet.

The problem is a few lines above, on the second line of the following:

     nvec q;
     q.len = (dividend.len - divisor.len + 1);
     q.vec = (uint32_t *) alloca(q.len * sizeof(uint32_t));
     rmemset(q.vec, 0, q.len * sizeof(uint32_t));

This and another bug (see below) should have been discovered much 
earlier, therefore i wondered whether I was the first to compile the 
xenv using a 64 bit compiler...

Using a 64bit compiler triggered things this way:

In BigNum::asString, the radix is converted to a bignum. When using a 
64bit compiler, size_t is 64 bit, so the bignum internally allocates 
space for a (32bit) digit string with to slots. So a literal 10 would be 
represented as "0, 10". The above code obviously assumes that there are 
no leading zeroes in the internal representation.

In order to fix the problem, I would like to know whether there are any 
validity constraints the implementation should guarantee. Fex. are 
leading zeroes allowed?

There's a relatively obvious bug around line 725 in BigNum.cxx
A patch is attached.

Regards
Thomas Stratmann
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bignum.patch
Url: http://www.coyotos.org/pipermail/coyotos-dev/attachments/20070930/bafcb365/attachment.pl