This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: NaN #defines
- To: Zack Weinberg <zack@rabi.phys.columbia.edu>
- Subject: Re: NaN #defines
- From: Ulrich Drepper <drepper@cygnus.com>
- Date: 16 Jun 1998 15:58:40 -0700
- Cc: libc-hacker@cygnus.com
- References: <199806162226.SAA13416@rabi.phys.columbia.edu>
- Reply-To: drepper@cygnus.com (Ulrich Drepper)
Zack Weinberg <zack@rabi.phys.columbia.edu> writes:
> We currently define NAN to be a single precision quiet NaN. All
> other unqualified math #defines are doubles; this is an odd
> inconsistency. Also, there's no way to get a signalling NaN. Perhaps we
> should extend the definitions?
>
> NAN double, quiet
> NANf single, quiet
> NANl extended, quiet
Not needed. I had this once since an ISO C 9x draft proposed them but
it is unnecessary since assigning NAN to a double variable will again
be a NAN without loss of "precision".
> NANs double, signal
> NANfs single, signal
> NANls extended, signal
First, signalling NAN are highly discussed in the IOS C 9x working
groups there are strong oponents. I want to wait to make any
definition about this until after the next ISO C 9x WG meeting.
And it isn't true that you cannot generate a sNAN, just use the nan()
function with the correct argument.
> Also, bits/nan.h isn't being included by math.h -- is this intentional?
Well, what actually isn't done is to include bits/nan.h when compiling
for ISO C 9x. It is included for _GNU_SOURCE. I'll change this.
--
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
- References:
- NaN #defines
- From: Zack Weinberg <zack@rabi.phys.columbia.edu>