Mail Archives: djgpp-workers/2003/04/22/09:23:42
Hello.
ams AT ludd DOT luth DOT se wrote:
[snip]
> Ok. This is what I have. All three functions are now implemented. I
> hope I haven't forgotten to incorporate any comments.
Thanks!
> 1. Note that the final paragraph in Return value for strtold is
> missing, in case you notice. It's because that isn't implemented.
> That's how it was.
You mean the paragraph about the function returning HUGE_VALL and errno ==
ERANGE, when the number is too big, right? Perhaps we should add that
paragraph, since:
* we may return HUGE_VALL, etc. at some point in the future;
* the standard specifies that we can return HUGE_VALL, etc.;
* and the programmer using the library should be aware that we can return
HUGE_VALL, etc.
> 2. You might want to look at the end of the changes of
> strtold.txh: "next most significant bit"?
How about the "second most significant bit" instead? It might be a good idea
to say that the first most significant bit is the integer bit, just in case
the reader is curious.
It's not clear which bit was the previous most significant bit was. So saying
"next" is confusing.
> 3. To do the right thing for strtold(), I need to know if the integer
> bit may be clear for a NaN representation. Otherwise I need to set it.
It sounds like you should set it, from the discussion between you and Eli.
> 4. I haven't changed _strtold()'s documentation. Should we really have
> the exact same documentation twice (except the portablity notes)? In
> the same file too?! There must be a better way to do this.
This is an issue with many other parts of the documentation. Until we come to
a decision, I think you should make the same edits to both files.
The alternatives are:
1. duplicate the description between similar functions;
2. have one description as the definite one and refer (@(|x|px)ref) to that
from the other ones;
3. put the description in another file and @include it in all the relevant
pages.
I prefer 3, but then you have problems setting up makeinfo's include path.
Perhaps we could use relative paths, to avoid this problem:
@include ansi/stdio/foo.txh
Then you'd only need to set up the include path, if you're not building in
src/libc.
> 5. Still no tests for strtold().
It would still be nice to have some, but I think the patch could go in without
them. If you have any spare time, maybe you could write some tests for
strtold... ;)
[snip]
> Index: djgpp/src/libc/ansi/stdlib/strtold.c
[snip]
> + if( s[3] == '(' )
> + {
> + unsigned long long mantissa_bits = 0;
> + char *endptr = unconst((&s[4]), char *);
> +
> + mantissa_bits = strtoull(&s[4], &endptr, 16);
> + if ( *endptr == ')' )
> + {
> + if( mantissa_bits )
> + {
> + n.mantissal = mantissa_bits & 0xffffffff;
> + n.mantissah = (mantissa_bits >> 32) & 0xffffffff;
The indentation looks inconsistent here.
[snip]
> Index: djgpp/src/libc/ansi/stdlib/strtold.txh
[snip]
> +If @var{s} is ``NaN(@var{hex-number})'', with any variations of case
> +and optionally prefixed with ``+'' or ``-'', the return value is a NaN
> +with the mantissa bits set to
> +@code{@var{hex-number}&0xffffffffffffffff} (the mantissa for long
> +doubles consists of 64bits). Use at most 16 hexadecimal digits in
[snip]
I think there should be a gap between "64" and "bits", like there is with "52"
and "bits" in the documentation for strtod.
Apart from that, the patch looks good to me. But I think you need to answer
Eli's concerns about FP emulation, before an updated patch can go in.
Thanks, bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
- Raw text -