Date: Wed, 20 Jan 1999 09:03:49 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: DJ Delorie <dj AT delorie DOT com>
cc: djgpp-workers AT delorie DOT com, moshier AT mediaone DOT net
Subject: Re: Bug when printing long doubles
In-Reply-To: <199901191742.MAA10687@envy.delorie.com>
Message-ID: <Pine.SUN.3.91.990120090250.2569B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com


On Tue, 19 Jan 1999, DJ Delorie wrote:

> Invalid strings are printed as "<null>".  Can't invalid FPs be printed
> as "<invalid>" ?

I don't mind to print "<invalid>", or maybe "<FPInvalid>".

> I mean, we still have to do the work to properly
> support this, but it's better than crashing.

It is quite easy to support this, I think.  The function `isspeciall'
from doprnt.c needs a trivial addition to produce any pattern we agree
upon, similarly to what it does today for "Inf" and "NaN".

> I also suspect that there are more NaN patterns than just the one that
> is "the" NaN pattern.  I wouldn't have a problem with "NaN" being
> printed for *all* invalid patterns (except known infinities and
> printable denormals, of course).

If we choose this approach, we must at least change the other functions 
that depend on that.  For example, `is_nan' should return 1 for these 
patterns as well.

AFAIK, there are clear-defined bit patterns for NaNs, at least as far
as the Intel processors are concerned.  Any special number that is
neither a normalized FP number, nor NaN, nor infinity, and not a
denormal, is described as ``unnormal'' in the references about x87
processors that I have.