Message-ID: <00ab01be431b$7d44ee40$60a46d86@robby.dittmannsdorf.de>
From: Robert Hoehne <robert DOT hoehne AT gmx DOT net>
To: DJGPP Mailing list <djgpp AT delorie DOT com>
Subject: Re: Bug when printing long doubles
Date: Mon, 18 Jan 1999 18:46:26 -0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id MAA02169
Reply-To: djgpp AT delorie DOT com

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


In my opinion it should produce "NaN". To clearify my opinion I will
descibe now the real situation.

I came to this, as I use now in RHIDE the patched GDB 4.17 (I sent
the patches already to the gdb-patches list) which enables me now
to get the FPU contents. Then in the disassembler window I want to
show the contents of each FPU register and if it is a floating point
register, then it should print the float value.

The trick with checking the status register does not work, since I
cannot assume, that such a register is available at all (only knowing
the GDB macros about the type of register). So I only have the raw
contents of the FPU register and want to sprintf it.

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


Yes, I know, but since gcc -O2 doesn't optimize it out, it fixes for
now my problem.

Robert