delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/03/15/09:27:55

Date: Wed, 15 Mar 2000 16:07:08 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Dieter Buerssner <buers AT gmx DOT de>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Unnormals???
In-Reply-To: <200003151300.IAA05344@delorie.com>
Message-ID: <Pine.SUN.3.91.1000315160007.19906A-100000@is>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Wed, 15 Mar 2000, Dieter Buerssner wrote:

> 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.

That's correct: we only print Unnormal for an argument of type long 
double.

> When you printf a NaN that was procuced by a sqrt domain error,
> it might print "nan(sqrt)". This, at least is my interpretation.

Can you tell on what this interpretation is based, or point to other 
platforms which do something similar?  I cannot find anything in the 
Standard's language that would hint on what those n-chars could be.

> Perhaps, it would be preferable, to print "nan(unnormal)" for the 
> unnormal case, to be std conform. 

Since I don't understand this aspect of the standard, it is not clear to 
me whether this would or would not be compliant.

Please note that we also print "(null)" for a NULL pointer, IIRC because 
this invokes an undefined behavior, where all bets are off.  If the 
standard says that passing an invalid FP number also invokes undefined 
behavior, what we do is compliant. 

> 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.

Did you check the latest library?  AFAIK, it doesn't suppress the sign of 
a NaN anymore, at least not in all cases.

> 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.

If you can make them consistent with the latest version of doprnt.c, I
suggest to post the diffs against the current sources here.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019