From: Message-Id: <200303182003.h2IK3aw16734@speedy.ludd.luth.se> Subject: Re: strto{d,f,ld}, inf and nan patch In-Reply-To: <3E775B18.5E9CA18D@phekda.freeserve.co.uk> "from Richard Dawe at Mar 18, 2003 05:44:56 pm" To: djgpp-workers AT delorie DOT com Date: Tue, 18 Mar 2003 21:03:36 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL78 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-MailScanner: Found to be clean Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Hulla. According to Richard Dawe: > Martin Stromberg wrote: > > Yes. All we need to agree on the format and if somebody else does the > > printing part, I'll do the strto{f,d,ld}() part. > [snip] > > If no-one else volunteers (seems unlikely), then I'll do the printing part. > Yet me know when you strto* patch is ready and I'll do the reverse > transformation in _doprnt. Superbly! I've decided to use "-nan" etc. to indicate a set sign bit (even though sign is irrelevant to nans). This solves the problem of forcing the sign bit into the non-existing 65th bit of a unsigned long long for long doubles or any weird multi-value a la "nan(1,2,3)". I did the docs (only strtod.txh yet) first this time: Index: djgpp/src/libc/ansi/stdlib/strtod.txh =================================================================== RCS file: /cvs/djgpp/djgpp/src/libc/ansi/stdlib/strtod.txh,v retrieving revision 1.3 diff -p -u -r1.3 strtod.txh --- djgpp/src/libc/ansi/stdlib/strtod.txh 29 Jan 2003 12:30:21 -0000 1.3 +++ djgpp/src/libc/ansi/stdlib/strtod.txh 18 Mar 2003 19:46:59 -0000 @@ -11,7 +11,9 @@ double strtod(const char *s, char **endp @subheading Description This function converts as many characters of @var{s} as look like a -floating point number into that number. If @var{endp} is not a null +floating point number into that number. It also recognises +(case-insensitivly) @code{Inf}, @code{Infinity}, @code{NaN} and +@code{NaN()}. If @var{endp} is not a null pointer, @code{*endp} is set to point to the first unconverted character. @@ -19,12 +21,33 @@ character. The value the represented by @var{s}. +If @var{s} is @code{Inf} or @code{Infinity}, with any variations of +case and optionally prefixed with ``+'' or ``-'', the return value is +@code{INFINITY} (if no prefix or a ``+'' prefix) or @code{-INFINITY} +(if the prefix is ``-''). + +If @var{s} is @code{NaN} or @code{NaN()}, with any variations of case +and optionally prefixed with ``+'' or ``-'', the return value is +@code{(double)NAN}. If the prefix is ``-'' the sign bit in the NaN +will be set to 1. + +If @var{s} is @code{NaN()}, with any variations of +case and optionally prefixed with ``+'' or ``-'', the return value is +a NaN with the mantissa bits set to @code{&0xfffffffffffff} +(the mantissa for doubles consists of 52 bits). If +@code{&0xfffffffffffff} is 0 (which is won't work as a +representation of a NaN) @code{(double)NAN} will be returned. If the +prefix is ``-'' the sign bit in the NaN will be set to 1. + If a number represented by @var{s} doesn't fit into the range of values representable by the type @code{double}, the function returns either @code{-HUGE_VAL} (if @var{s} begins with the character @code{-}) or @code{+HUGE_VAL}, and sets @code{errno} to @code{ERANGE}. @subheading Portability + +@port-note ansi-c99 Support for @code{Inf}, @code{Infinity}, +@code{NaN} and @code{NaN(@dots{})} was standardised in ANSI C99. @portability ansi, posix > BTW our current implementation of nan* is non-conforming. The ANSI C99 takes a > char * argument (i.e.: in NaN(), but the prototype in > . gcc 3.3 generated a warning for nan*. You are talking about include/libm/math.h, right? 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? Otherwise you need to elaborate as I don't understand. > 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.) Right, MartinS