Re: Serious bug in GUILE rational handling.

[Kevin Ryde]

Han-Wen Nienhuys <address@hidden> writes:
>
> This took a lot of effort to debug; printing the rational while
> debugging would alter the reduction bit, making the problem go away,
> suggesting memory corruption rather than a programming error.

Nasty.

> Suppose another thread triggers scm_i_fraction_reduce at the same
> time, and reads the partial result of the first scm_i_fraction_reduce.
> This is really insidious, as the corruption would happen upon reading
> the data, and will show up somewhere completely different.

Yep.  I think I might have raised that when fractions were introduced,
then promptly never did anything about it.  My best idea at the time
was if fractions are stored unreduced then gc would be a good
thread-safe place to look for reductions to save space.

I don't know if reduced or unreduced is a better representation.  My
guess would be that gcds are so horrendously expensive that unreduced
is often what you want, if it's do-able.  Reducing lazily sounds like
the best of both worlds, but as you point out would need multithread
protection.

> I am about to commit these changes to CVS, and will also commit them
> to the GUILE 1.8 branch.

Do you have a test case for numbers.test?  Not that I doubt the fix,
just to illustrate what now works.

I took the liberty of adding a NEWS entry too.