Date:	Wed, 20 Jan 1999 08:19:17 -0500 (EST)
From:	Stephen L Moshier <moshier AT mediaone DOT net>
X-Sender:	moshier AT moshier DOT ne DOT mediaone DOT net
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Bug when printing long doubles
In-Reply-To:	<Pine.SUN.3.91.990120090527.2569D-100000@is>
Message-ID:	<Pine.LNX.4.05.9901200812570.17035-100000@moshier.ne.mediaone.net>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com

On Wed, 20 Jan 1999, Eli Zaretskii wrote:
> I think, ultimately, we must be compatible with the processor that
> runs the code (without violating standards, of course).  For this
> reason, it is IMHO wrong to print "NaN" for something the processor
> doesn't consider as such.  We need to find a different string.
> 

The C9X standard seems to require `NAN' but it may be followed by
additional characters.  DEC alpha osf currently prints `NaNQ' for
a quiet NaN.

               A
               double argument representing a NaN is  converted  in
               one of the styles [-]nan or [-]nan(n-char-sequence)
                --   which  style,  and  the meaning of any n-char-
               sequence,   is   implementation-defined.    The    F
               conversion  specifier produces INF, INFINITY, or NAN
               instead of inf, infinity, or nan, respectively.218)

- Raw text -