Re: RFA: don't try to compare IEEE NaN's

[Fernando Nasser <fnasser@redhat.com>]

Eli Zaretskii wrote:
> 
> On 6 Jun 2001, Jim Blandy wrote:
> 
> > > I think it is better to initialize the integral members of the union
> > > with an explicit bit pattern, just not a pattern which gets
> > > interpreted as a NaN or an Inf.  With initialization such as above,
> > > you risk losing due to subtleties of compile-time conversion of a
> > > literal constant to a floating-point value.  This is a GDB test suite,
> > > so we are not interested in testing the compiler.
> >
> > I'm not sure what you mean.  Once the test has assigned a value to
> > testval.float_testval, we only use that variable.  The compile-time
> > conversion happens exactly once, and then we always use the result of
> > that conversion.
> 
> Let's begin by asking why do you at all set the members of the union to
> specific values?  Why not initialize them to zero, or even leave them at
> some random garbage they pick up from the stack?
> 
> My assumption was that whoever wrote the test wanted to see that GDB
> doesn't lose bits due to all kinds of conversions that are going under
> the hood.  If that is true, you want to make sure the value you work with
> has the same bit pattern you wanted it to have.  If not, you don't really
> know what you are testing here; for example, imagine an (absurdly
> unrealistic) case that the compiler turns your literal constant into an
> all-zero bit pattern, or into a NaN.  Then you are back to square one.
> 
> The only way to make sure you get the bit patterns you wanted is to
> initialize the integral members of the union with those bit patterns.
> You just want them to be different from a NaN or an Inf, because they
> cause trouble in comparisons.
> 
> Am I making any sense?

I believe there will be many failures before that happen.

But, yes, loading the variables with known bit patterns would be immune
to that.  On the other hand, what would be the bit  pattern?  If we use
the IEEE one it may break in systems that do not use IEEE.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9