This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: don't try to compare IEEE NaN's
- To: Jim Blandy <jimb at cygnus dot com>
- Subject: Re: RFA: don't try to compare IEEE NaN's
- From: Michael Snyder <msnyder at cygnus dot com>
- Date: Wed, 06 Jun 2001 10:55:06 -0700
- CC: Eli Zaretskii <eliz at is dot elta dot co dot il>, gdb-patches at sources dot redhat dot com
- Organization: Red Hat
- References: <Pine.SUN.3.91.1010606184023.18730A-100000@is> <npn17l4ife.fsf@zwingli.cygnus.com>
Jim Blandy wrote:
>
> Eli Zaretskii <eliz@is.elta.co.il> writes:
> > 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.
>
> What you're saying is that, between this:
>
> union {
> float f;
> char bytes[80];
> } u;
>
> for (i = 0; i < 80; i++)
> u.bytes[i] = something interesting;
>
> and this:
>
> u.f = 2.7182818284590452354;
>
> that you're more concerned that the latter will put a NaN in u.f than
> the former. When, in fact, the exact problem I'm trying to fix is
> that someone's first shot at the former strategy produced a NaN.
"Someone" is me. I of course knew that FFFFFFFF would be a NaN --
I just didn't know that NaN could not be compared to itself on
some platforms. BTW, the reason for using a union as I did,
rather than individual char, short, int etc. variables, was to
make sure that the known bit pattern was actually larger than
the type being tested -- so that we would know if, for instance,
GDB was testing more bits than it should.