Mail Archives: djgpp/1999/01/18/12:49:36
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
|
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
|
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
- Raw text -