Message-Id: <200003221407.JAA07300@delorie.com>
From: "Dieter Buerssner" <buers AT gmx DOT de>
To: djgpp-workers AT delorie DOT com
Date: Wed, 22 Mar 2000 15:08:08 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Unnormals???
CC: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
References: <200003201825 DOT UAA28340 AT is DOT elta DOT co DOT il>
In-reply-to: <Pine.SUN.3.91.1000322102606.17945E-100000@is>
X-mailer: Pegasus Mail for Win32 (v3.12b)
Reply-To: djgpp-workers AT delorie DOT com

On 22 Mar 00, Eli Zaretskii wrote:

> On Mon, 20 Mar 2000, Dieter Buerssner wrote:
> 
> > The original version has a bug in isspeciall, so it prints
> > +unnormal, --unnormal
> 
> By ``bug'' what exactly do you mean?  The double minus sign is indeed
> a bug, but the "unnormal" part isn't, I think.

I meant both, not printing NaN and the double minus. 

> > static const unsigned short pos_nanshort[] = {0,0,0,1,0x7fff,0};
> > static const unsigned short neg_nanshort[] = {0,0,0,1,0xffff,0};
> 
> When converted to a long double, these two have the following bit
> patterns:
> 
>  pos_nanshort = 7fff 0001 0000 0000
>  neg_nanshort = ffff 0001 0000 0000

Have your forgotten 0000 at the end of the previous two lines?

> These are indeed unnormals: their mantissa has a zero MSB.

I think, they are not unnormals. I think this discussion has shown,
that unnormals must have a finite exponent.

> If you wanted _doprnt to support so-called pseudo-NaNs, as described
> in section 7.4.4 of the Intel manual, then we indeed need to reserve
> the 0x7fff exponent for a NaN.  But _doprnt currently doesn't support
> pseudo-NaNs (and I'm not sure it should).

I think it should, and it also did this before the unnormal check was
added. (Yes, it was my error not thinking about the unnormal case
when adding long double support to _doprint.)

Regards,
Dieter