Mail Archives: djgpp-workers/2000/03/15/09:27:55
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 -