Message-Id: <200003151300.IAA05344@delorie.com>
From: "Dieter Buerssner" <buers AT gmx DOT de>
To: djgpp-workers AT delorie DOT com
Date: Wed, 15 Mar 2000 14:00:05 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Unnormals???
References: <200003142156 DOT WAA20972 AT father DOT ludd DOT luth DOT se>
In-reply-to: <Pine.SUN.3.91.1000315105430.17230R-100000@is>
X-mailer: Pegasus Mail for Win32 (v3.12b)
Reply-To: djgpp-workers AT delorie DOT com

On 15 Mar 00, Eli Zaretskii wrote:

> We print Unnormal for something that is not a valid FP number, like if
> you fill a buffer with arbitrary text and then pass it to a function
> which expects a double.

Let me add, that when I am not totally mistaken, there can be no 
unnormals for type double (or float), because these types have and
implicit set bit msb for the mantissa. This is not true for type long 
double.
 
[...]
> > The standard doesn't mention them. Is this ok?
> 
> The standard also doesn't say it cannot be done.

I read 17.19.6.1 in the C99 draft. To me it seems it does not allow 
this. 

> > The standard seems to say we should print
> > "[-]nan" or "[-]nan(n-char-sequence)" ("n-char-sequence" is in
> > italics). What is n-char-sequence supposed to be?
> 
> I didn't understand this when I read it, either.  Anybody?

There are many differen NaNs. A math library can choose, to encode
some information in the NaN, to help debugging. So when you find
a NaN at some check-point in your program, you are able to say, that
this NaN was produced by, say, sqrt().  (When you call sqrt(NaN), 
sqrt() will not return its own NaN, but rather the NaN in the 
argument.)

When you printf a NaN that was procuced by a sqrt domain error,
it might print "nan(sqrt)". This, at least is my interpretation.
Perhaps, it would be preferable, to print "nan(unnormal)" for the 
unnormal case, to be std conform. 

Also, when reading the printf chapter in the C99 draft,  (especially 
what Martin has cited) it is clear that the kludge, to suppress the 
sign of the NaN (I added this years ago, when I sent a patch for
support of long double) is clearly wrong. I did not have any standard
at that time, and tried to mimic other C implementations, that did 
not print the sign of the NaN.

Martin, are you working at printf implementation?
I have written some code for accurate bin <-> dec conversion for 
djgpp1x. I had no net access at that time. I didn't merge the patches
with the newer library. When you are interested, let me know.

Regards,
Dieter