Date: Wed, 15 Mar 2000 16:07:08 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Dieter Buerssner cc: djgpp-workers AT delorie DOT com Subject: Re: Unnormals??? In-Reply-To: <200003151300.IAA05344@delorie.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.