Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3E888DDF.21E2114F@phekda.freeserve.co.uk>
Date: Mon, 31 Mar 2003 19:50:07 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: DJGPP workers <djgpp-workers AT delorie DOT com>
Subject: _doprnt and NaNs
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

I've been looking at supporting the new C99 features in printf for NaNs. This
involves modifying _doprnt. I have something that works. Unfortunately there
are some problems.

The code in _doprnt (well, cvtl and isspeciall) works with floats stored in
long doubles. When you do, say:

    printf("%f", NAN);

the NAN is first converted in _doprnt to a double by the va_arg macro, then to
a long double.

So NAN does not appear as "nan" or "nan(0x7fffff)", as you might expect. It
appears as "nan(0xffffff00000000)". 

NB: The mantissa of NAN is 0x7fffff.

NB: I have modified the code to display manh from IEEExp as the left-most
digits. Please let me know, if that's not correct.

So, is it acceptable for NAN not to appear as "nan(0x7fffff)"?

If it's not reasonable, then it could be tricky. The _doprnt code has no idea,
whether the original number was a float or a double, because there's no
float-specific type specifier. (e, f, g are for doubles. Le, Lf, Lf are for
long doubles.)

It seems reasonable to me, if the following code gives a plain NAN (*) as
output ('f'):

    char buf[128];
    float f;

    sprintf(buf, "%f", NAN);
    f = strtof(buf, NULL);

I have not tested this yet.

(*) Curry fans: I apologise for the pun. It wasn't intentional.

Bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]