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: Eli Zaretskii <eliz at is dot elta dot co dot il>
- Subject: Re: RFA: don't try to compare IEEE NaN's
- From: Jim Blandy <jimb at zwingli dot cygnus dot com>
- Date: 06 Jun 2001 12:39:01 -0500
- Cc: Jim Blandy <jimb at cygnus dot com>, gdb-patches at sources dot redhat dot com,msnyder at cygnus dot com
- References: <Pine.SUN.3.91.1010606184023.18730A-100000@is>
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.
This seems silly.