X-Authentication-Warning:	acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date:	Wed, 20 Jan 1999 12:46:45 +0100 (MET)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	djgpp workers list <djgpp-workers AT delorie DOT com>
Subject:	Re: Bug when printing long doubles
In-Reply-To:	<Pine.SUN.3.91.990120130515.18751A-100000@is>
Message-ID:	<Pine.LNX.3.93.990120122737.2655C-100000@acp3bf>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com

On Wed, 20 Jan 1999, Eli Zaretskii wrote:
> On Wed, 20 Jan 1999, Hans-Bernhard Broeker wrote:
> 
> > It should print the actual value. After all, even an unnormalized fp
> > number does have a value.
> 
> I thought about such a possibility (it seems that Linux, at least in some 
> versions, does that), but decided I don't like it.  The reason is that if 
> you print it as a normal FP number, how does John Doe the programmer, who 
> has his program crash or produce NaNs, will ever be able to guess that 
> this number is the culprit?  
[...]
> You can't multiply this number by anything: if you do, you get a NaN as a 

Hmmm... seems like I'll have to revisit my FPU literature again. I thought
the FPU at least had a mode where it does not generate any exception, nor
return NaN, when it's operating on unnormals...

> > On a side issue: as per the C9x standard, it seems we'll have to change
> > from 'NaN' and 'Inf' to 'nan' and 'inf' at some point in time.
> 
> Does C9X indeed diverge from existing art so much?  Do they disallow Inf 
> and NaN?

Well, to quote the draft, revision 2, from the description of the fprintf
'%f' format:

               A   double  argument  representing  an  infinity  is
               converted in one of the styles [-]inf or [-]infinity
                --    which  style  is  implementation-defined.   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)

With the footnote 218 saying:

       218When applied to infinite and NaN values, the  -,  +,  and
          space flag characters have their usual meaning; the # and
          0 flag characters have no effect.

%e and %g are documented to behave like %f, on NaN and and infinity. 

Now, what does the 'style [-]nan' mean, exactly? As I read it, it means: 
print "nan", in exactly these letters, with an optional minus in front. 
The fact that all these 'style' strings are given in bold (in the pdf
edition of draft 1, I have), and that the are written NAN, and INFINITY,
in the case of %F/%G/%E, seems to support this.

	
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -