Date:	Sun, 17 Jan 1999 11:58:32 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Robert Hoehne <robert DOT hoehne AT gmx DOT net>
cc:	djgpp AT delorie DOT com
Subject:	Re: Bug when printing long doubles
In-Reply-To:	<369E7C19.DBF14CB6@gmx.net>
Message-ID:	<Pine.SUN.3.91.990117115802.278B-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com

On Thu, 14 Jan 1999, Robert Hoehne wrote:

> I know, that the value might be invalid. It is not an constructed
> example but it comes from real live. I simply thought, that the
> doprnt() function should handle this, which it doesn't.

Handle--how?  In v2.01, `doprnt' would simply crash with SIGFPE.
v2.02 masks all FP exceptions, and so this value gets into cvtl where
it blows up the stack (as the 0x30303030 value on the stack clearly
shows).

The question is: what do you want such invalid numbers to produce?
NaN seems not quite right, since a NaN has a special bit pattern,
which that number isn't.

If we agree on what `doprnt' should produce in such cases, then it
shouldn't be hard to fix this.

> >         long double ld;
> > 
> >         ld = *(long double*)i;
> >         ld+=0;
> > 
> > Now your sprintf will produce the output 'NaN' because the operation
> > produces a NaN.
> 
> Thanks for that hint. I'll try this and if it fixes it, I'll
> use it.

Beware: a good optimizer will optimize away "ld += 0;" and you might
still crash.

- Raw text -