Serious bug in GUILE rational handling.

[Han-Wen Nienhuys]

Hello,

scm_equal_p inspects SCM_CELL_TYPE() of a rational. Cell type is also used
to hold the reduced bit. This leads to interesting behavior,

guile> (define x 1/2)
guile> (define y 1/2)
guile> (denominator x)
2
guile> (equal? x y)
#f
guile> 


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.

Furthermore, I think

  if (!(SCM_FRACTION_REDUCED (z)))
    {
      SCM divisor;
      divisor = scm_gcd (SCM_FRACTION_NUMERATOR (z), SCM_FRACTION_DENOMINATOR 
(z));
      if (!(scm_is_eq (divisor, SCM_I_MAKINUM(1))))
        {
          /* is this safe? */
          SCM_FRACTION_SET_NUMERATOR (z, scm_divide (SCM_FRACTION_NUMERATOR 
(z), divisor));
          SCM_FRACTION_SET_DENOMINATOR (z, scm_divide (SCM_FRACTION_DENOMINATOR 
(z), divisor));
        }
      SCM_FRACTION_REDUCED_SET (z);
    }

introduces a race condition.

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.

I have removed support for the reduced bit, and put the reduction in
make_fraction.

I am about to commit these changes to CVS, and will also commit them
to the GUILE 1.8 branch.  I would appreciate it if a GUILE 1.8.2 would
be released ASAP.  I need working rational numbers in GUILE for
LilyPond 2.11.x, and it would be nice if I didn't have to force my
users to run GUILE from CVS.

--
 Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen