[coyotos-dev] BigNum.cxx buglet?

[Jonathan S. Shapiro]

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.

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
this afternoon (I'm testing now).

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

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.

shap
-- 
Jonathan S. Shapiro
Managing Director
The EROS Group, LLC
www.coyotos.org, www.eros-os.org