Mail Archives: djgpp-workers/2003/03/18/15:03:43
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(<optional integer>)}. 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(<integer>)}, with any variations of
+case and optionally prefixed with ``+'' or ``-'', the return value is
+a NaN with the mantissa bits set to @code{<integer>&0xfffffffffffff}
+(the mantissa for doubles consists of 52 bits). If
+@code{<integer>&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.: <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?
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
- Raw text -