This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: NaN #defines


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   `------------------------


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]