Message-ID: <369E7C19.DBF14CB6@gmx.net>
Date: Thu, 14 Jan 1999 22:22:01 -0100
From: Robert Hoehne <robert DOT hoehne AT gmx DOT net>
Organization: none provided
X-Mailer: Mozilla 4.07 [de] (Win95; I)
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: Bug when printing long doubles
References: <369BD204 DOT 4C3E3AD2 AT gmx DOT net> <369d3c25 DOT 56805751 AT news DOT snafu DOT de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com

Horst Kraemer wrote :
> 
> The problem is that the long double value you specified:
> 
>     A33A 6F....
>      exp significand
> 
> is an 'unnormal', i.e. a FP number where bit #63, the implied 1.0 of

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. I came
to this, when I read out the FPU stack and then print the contents.
And if a FPU register is not used, it might have such a value in it.

> In order to circumvent the problem you may load the value to a ld
> variable and perform an operation like
> 
>         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.

Robert
-- 
******************************************************
* email:   Robert Hoehne <robert DOT hoehne AT gmx DOT net>     *
* Post:    Am Berg 3, D-09573 Dittmannsdorf, Germany *
* WWW:     http://www.tu-chemnitz.de/~sho/rho        *
******************************************************