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
Content-Type: TEXT/PLAIN; charset=US-ASCII
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)