Date: Tue, 19 Jan 1999 11:38:25 +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-workers AT delorie DOT com, "K.B. Williams" <Kbwms AT aol DOT com>,
        Stephen L Moshier <moshier AT mediaone DOT net>
Subject: Re: Bug when printing long doubles
In-Reply-To: <00ab01be431b$7d44ee40$60a46d86@robby.dittmannsdorf.de>
Message-ID: <Pine.SUN.3.91.990119112518.12893G-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com

[Redirected to djgpp-workers, as I think this is the proper place to 
discuss it.  I attach the original message from Robert at the end,
for those who might have missed it.]

On Mon, 18 Jan 1999, Robert Hoehne wrote:

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

I'm not sure NaN is quite right.  A NaN has special well-defined bit 
pattern, which your case didn't have.  So printing "NaN" could surprise 
somebody.

Numbers such as what you used are known as "Unnormal" or "Special": the 
first bit of the mantissa is zero, but the exponent is NOT zero.

FSDB, for example, tags that number as "Special".

So how about printing "Unnormal" or "Special" (with or without a sign)?

Here's the original report posted by Robert:

Date:         Tue, 12 Jan 1999 21:51:48 -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 Mailing list <djgpp AT delorie DOT com>
Subject:      Bug when printing long doubles
Reply-To:     djgpp AT delorie DOT com

I haven't the time to seach deeper for that bug, so
I thought that I report it.

Here at first the test program
---file pr.c--------------------------------------------------
#include <stdio.h>

int main()
{
  char buf[100];
  unsigned char i[10] = {
    0x13,
    0x22,
    0xf7,
    0xfc,
    0x2f,
    0x3e,
    0x28,
    0x6f,
    0x3a,
    0xa3 };
  sprintf(buf, "%*.17LG", 16, *((long double *)i));
  fprintf(stderr, "%s\n", buf);
  return 0;
}
--end of pr.c-----------------------------------------------------

the program was build with

gcc -o pr.exe pr.c doprnt.c -g

(where doprnt.c is from the DJGPP 2.02 libc sources)

and here now the traceback:

O:\RHIDE\TEST>pr
Exiting due to signal SIGSEGV
General Protection Fault at eip=00003490
eax=00000030 ebx=00008355 ecx=0008e974 edx=3008e9f6 esi=00000054 edi=0008fdd6
ebp=0008e9fc esp=0008e984 program=F:\OBJ\RHIDE\TEST\PR.EXE
cs: sel=00a7  base=83557000  limit=0009ffff
ds: sel=00b7  base=83557000  limit=0009ffff
es: sel=00b7  base=83557000  limit=0009ffff
fs: sel=0087  base=0000d5e0  limit=0000ffff
gs: sel=00c7  base=00000000  limit=0010ffff
ss: sel=00b7  base=83557000  limit=0009ffff
App stack: [0008ff08..0000ff08]  Exceptn stack: [0000fdf0..0000deb0]

Call frame traceback EIPs:
  0x00003490   cvtl, line 556 of doprnt.c
  0x30303030

O:\RHIDE\TEST>gsymify -o pr.out pr.exe

OK, I hope, someone will have the time to find the
bug (and a patch).

Robert