X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Date: Fri, 04 Jan 2002 11:06:39 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp-workers AT delorie DOT com
Message-Id: <1858-Fri04Jan2002110639+0200-eliz@is.elta.co.il>
X-Mailer: emacs 21.1.50 (via feedmail 8 I) and Blat ver 1.8.9
CC: Kbwms AT aol DOT com
In-reply-to: <200201032140.WAA06212@father.ludd.luth.se> (message from Martin
	Str|mberg on Thu, 3 Jan 2002 22:40:48 +0100 (MET))
Subject: Re: Function nan()
References:  <200201032140 DOT WAA06212 AT father DOT ludd DOT luth DOT se>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
> Date: Thu, 3 Jan 2002 22:40:48 +0100 (MET)
> 
> Can tagp make a signaling NaN?

That's not an important question right now; if my message somehow
caused this to be an issue, I'm sorry.  I didn't mean to say that we
should support SNaN, I wanted to say that the optional tag string
could cause nan and strtod to produce one of the several bit patterns
defined by IEEE and Intel for a NaN.

What I'm wondering is (a) whether this is a correct interpretation of
the C9x standard, and (b) what strings are supported by other
implementations (so we could be compatible to some extent).

I looked on a GNU/Linux machine, but unfortunately, glibc.info does a
bad job of documenting what it does with that string: it simply
repeats the standard's wording, including the ``implementation-defined''
part(!).  Why the heck does it make sense to say in the docs of a
specific implementation that some behavior is ``implementation-defined''?