From: Markus <markus@...>
Date: 2004-08-31T23:48:51+09:00
Subject: Re: (Revised) [PATCH] Subtle bug in bignum.c

I am confused again.  I thought the problem was not with the
_parameters_ x & y, but rather with the clones of them that wind up
being stored in the same variables (if the value is negative, the
program modifies the parameter, replacing it with a modified clone of
the original).  

I've always thought (but remember, I don't really know C) that volatile
was a hint to the compiler that code that _used_ something should _not_
hold it in a register, because something else might modify it at any
time (e.g. the system clock).  So I am not sure why it would help.

In any case, is trying to force the addresses into registers better than
just temporarily marking them as not-to-be-reaped as I have done in the
revised patch?  It seems to me that the whole trick of leaving things in
registers and hoping the garbage collector sees them is untrustworthy in
the first place.  Couldn't the specter of better optimization inducing
bugs you raised in your previous post haunt us any time we depended on
the gc somehow knowing we still wanted something just because its
address was in a register?

Or am I missing something?

-- Markus


On Tue, 2004-08-31 at 07:25, ts wrote:
> >>>>> "M" == Markus  <markus@reality.com> writes:
> 
> M> I did not do anything with "volatile," in part because I am not really a
> M> C programmer, but mostly because (as I explained in the note after the
> M> revised patch), I don't trust the idea of leaving things in registers in
> M> the hopes that other, unrelated code will find them there.
> 
>  Well, probably I'm wrong but if you write it
> 
>    VALUE
>    rb_big_and(x0, y0)
>        VALUE x0, y0;
>    {
>        volatile VALUE x = x0;
>        volatile VALUE y = y0;
> 
>  I think that perhaps it will work.
>   
>  Probably it best to do the same with rb_big_xor() and see if this case can
>  exist with other functions in bignum.c
> 
> 
> Guy Decoux
> 
> 
> 
> 
>