This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [ezolt@perf.zko.dec.com] libc/1882: atof("NaN") doesn't return quiet NaN and doesn't detect IEEE mode.
- To: Phillip Ezolt <ezolt at perf dot zko dot dec dot com>
- Subject: Re: [ezolt@perf.zko.dec.com] libc/1882: atof("NaN") doesn't return quiet NaN and doesn't detect IEEE mode.
- From: Richard Henderson <rth at twiddle dot net>
- Date: Wed, 13 Sep 2000 10:41:22 -0700
- Cc: Andreas Jaeger <aj at suse dot de>, libc-alpha Mailinglist <libc-alpha at sourceware dot cygnus dot com>
- References: <u8zolobjxc.fsf@gromit.rhein-neckar.de> <Pine.OSF.3.96.1000913110308.29321G-100000@perf.zko.dec.com>
On Wed, Sep 13, 2000 at 11:20:18AM -0400, Phillip Ezolt wrote:
> If the user has specified that he/she does not want ieee compliance, we
> should return what makes the most sense for the user, by avoiding
> unneeded FPEs. atof("NaN") should evaluate to 0.
If the user has specified they don't want ieee compliance, what the
fuck are they asking for a NaN for? Zero is as bad an answer as 2.
> Older versions of GNU libc returned zero all the time.
Only by accident. I bet you'll find they *never* returned NaN.
> The SIGFPE is only part of the problem. The glibc is not returning
> what hardware would return (0xfff8000000000000).
An insignificant point. One quiet NaN is as good as another.
How could it possibly make a difference either way? They both
print as NaN, they both compare not equal to one another, they
both fault in non-ieee mode.
> Tru64 determines at run-time what ieee mode is set and picks the appropriate
> function. Can this be done in Glibc?
No it doesn't. It determines at link time, through disgustingness in
the ECOFF format. No this cannot be done with glibc, or ELF at all.
We can play funny games with header files and alternate function names
to determine the choice at compile time. I gave you an example how
in the previous message.
r~