Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3E786DE4.CEDBE28C@phekda.freeserve.co.uk>
Date: Wed, 19 Mar 2003 13:17:24 +0000
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 AT delorie DOT com
Subject: Re: strto{d,f,ld}, inf and nan patch
References: <200303182003 DOT h2IK3aw16734 AT speedy DOT ludd DOT luth DOT se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

ams AT ludd DOT luth DOT se wrote:
> 
> Hulla.

Hei!

> According to Richard Dawe:
[snip]
> > BTW our current implementation of nan* is non-conforming. The ANSI C99
> > takes a char * argument (i.e.: <anything> in NaN(<anything>), but the
> > prototype in <math.h>. gcc 3.3 generated a warning for nan*.
> 
> You are talking about include/libm/math.h, right?

No, include/math.h.

bash-2.04$ grep nan include/math.h
extern int isnan(double);
extern double nan(void);
extern int isnanf(float);
extern float nanf(void);

> If so, then that isn't a C99 standard header. And as we are going to
> move around or recode parts anyway that's not a big deal. However I'm
> unsure how and if we can seperate the stuff properly. And I suppose
> libm needs to be upgraded to C99 too?

Yes, libm needs upgrading. I actually put K. B. Williams's stuff in libc in
one of my CVS trees, but I'm starting to think it should go in libm. Our libm
and K. B. Williams's stuff seem to be derived from the same source: fdlibml.

> Otherwise you need to elaborate as I don't understand.

I was just saying that there's something else to fix.

> > Having said that, our implementations of nan* are not in the ANSI section.
> 
> Isn't that because they weren't in C89? (I haven't actually checked.)

I don't have C89, but the text in new POSIX suggests that they weren't in C89.

Bye, Rich =]

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