Mail Archives: djgpp-workers/2003/04/06/10:24:55
HELO
Richard said:
> But I still don't think that this identity will hold: strtof(sprintf(F)) == F.
It can't (if F is a NaN) as any float is converted to a double before
being pushed on the stack by the calling routine (which results in
some hardware specific mangling).
> Consider the test program t-nan4.c:
>
> ---Start t-nan4.c---
> #include <stdio.h>
> #include <stdlib.h>
> #include <libc/ieee.h>
>
> int
> main (void)
> {
> float_t ft;
> double_t dt;
> float f;
> double d;
>
> ft.mantissa = 1U;
> ft.exponent = 0x7fU;
> ft.sign = 0U;
>
> f = *(float *) &ft;
> d = f;
> dt = *(double_t *) &d;
>
> printf("float(0x%x, 0x%x, 0x%x) -> double(0x%x:0x%x, 0x%x, 0x%x)\n",
> ft.mantissa, ft.exponent, ft.sign,
> dt.mantissah, dt.mantissal, dt.exponent, dt.sign);
>
> return(EXIT_SUCCESS);
> }
> ---End t-nan4.c---
>
> This produces this output for me:
>
> float(0x1, 0x7f, 0x0) -> double(0x0:0x20000000, 0x3ff, 0x0)
>
> The float nan(0x1) has been converted into a double version. This would get
> formatted by sprintf as "nan(0x20000000)". But then strtof will convert it to
> an all-ones NaN, which is not the same as we started with.
Right. But we can't stop float-double promotion to *printf().
Interesting that it stayed a SNaN (if I see the bits right). (This
doesn't match my tests.)
> I'm starting to think that printf should not output nan(0x...), if
> strtox(sprintf(X)) == X identities don't all hold. But it seems wrong to have
> asymmetric support in printf & strto*.
For the float case it almost meaningless, but for the other formats
where (hopefully) the bit patterns remain untouched by the hardware
it's still useful. (Useful for somebody trying to understand where the
NaN came from supposedly.)
Right,
MartinS
- Raw text -