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 -