Date:	Wed, 20 Jan 1999 13:13:21 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Bug when printing long doubles
In-Reply-To:	<Pine.LNX.3.93.990120112136.2655A-100000@acp3bf>
Message-ID:	<Pine.SUN.3.91.990120130515.18751A-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com

On Wed, 20 Jan 1999, Hans-Bernhard Broeker wrote:

> It should print the actual value. After all, even an unnormalized fp
> number does have a value.

I thought about such a possibility (it seems that Linux, at least in some 
versions, does that), but decided I don't like it.  The reason is that if 
you print it as a normal FP number, how does John Doe the programmer, who 
has his program crash or produce NaNs, will ever be able to guess that 
this number is the culprit?  E.g., imagine that `sprintf' is used by a 
debugger to display such numbers (which is the context where Robert 
discovered this problem in the first place), or even simple printf 
debugging.

> Of course, it my turn out to be quite tricky to get this done
> right (we'ld have to normalize the number ourselves, by multiplying it by,
> say, 1e100, and then keep in mind to modify the exponent of the printed
> number accordingly). 

You can't multiply this number by anything: if you do, you get a NaN as a 
result.  This is exactly the reason that I don't think printing it as a 
normal number is a good idea: how could anybody guess why a perfectly
valid number yields a NaN when multiplied by another valid number?

So making this happen requires to fiddle with bits, any FP instruction is 
a no-no.  Of course, shifting bits isn't exactly rocket science, either...

> On a side issue: as per the C9x standard, it seems we'll have to change
> from 'NaN' and 'Inf' to 'nan' and 'inf' at some point in time.

Does C9X indeed diverge from existing art so much?  Do they disallow Inf 
and NaN?

- Raw text -