[coyotos-dev] BigNum.cxx buglet?

[Thomas Stratmann]

Jonathan S. Shapiro schrieb:
> Before I respond to any of this, thank you to all of the people who are
> trying to make this work on 64-bit platforms.
> 
> The Coyotos tool chain does not currently support cross-compilation from
> 64-bit platforms. NONE of the code has been tested in that scenario, and
> you may reasonably expect that there will be many bugs for that case.
Since I have a 64 bit system next to me, I am willing to put some effort 
into this. Out of personal interest as well.

> 
> Concerning the first bug:
> 
>>> In particular capidl loops endlessly in BigNum.cxx line 260:
>>>
>>>     ....
>>>     while (n3.len > n1.len) {
>>>       n3.vec[n3.len-1] = 0;
>>>     }
> 
> Most definitely a bug. Don't know how that got in there. Fix will go out
Obviously. The loop condition is constant.

>> 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...
> 
> Actually, the original bug was above this in the implementation of '/'
> and '%', where a target vector length of zero was being used to suppress
> unwanted outputs.

Sorry my fault: I misread the original code line number.

I had capidl endlessly looping here (line 371)

     for (size_t i = 0; i < bits; i++) {
       size_t bitndx = bits - i - 1;

       vu_set_bit(q, bitndx);

       vu_mul(divisor, q, tmp);
       if (vu_cmp(tmp, dividend) > 0)
	vu_clear_bit(q, bitndx);
     }

because q.len == 0.

Having corrected myself, my original description of the error should 
make sense now. (look ten lines above for

     q.len = (dividend.len - divisor.len + 1);

and think of the case divident.len==1, divident.oneDigit==255,
divisor.len==2, divident's digits being 0, 10 to represent "10")

> 
> I applied a variant of the asString patch using getDigit().
> 
> 
>> 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?
> 
> In the nvec structure, leading zeroes are allowed. Those zeroes are
> eliminated when the nvec structure is converted back to a BigNum at the
> end of the current operation.

This means that the "q.len =..." line is a bug because the leading zero 
case is not taken care of, right?

Thomas