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

- Raw text -