question on wrong result for small numbers from strtod(), strtof()
Sat Dec 4 10:54:00 GMT 2010
I have looked at this problem and believe the fault lies in assuming
that 9 < DBL_DIG + 1. The code breaks up the mantissa into 9 digits (y
value) and the rest of the digits (z value). When greater than 9
digits, it stops adding digits to the z mantissa when the number of
digits exceeds DBL_DIG + 1. However, in this scenario, DBL_DIG+1 is 7.
It should not have accepted and used the 8th and 9th digit when
forming the integer mantissa y and should of stopped at 7 digits.
This accounts for the 10**2 difference you are seeing as the mantissa
has been built up by 2 extra decimal digits more than expected later on
in the code.
I have made a patch which looks at DBL_DIG+1 first, then either adds the
digits to y or z based on whether there are 9 or more digits.
Please try out the patch and Craig look it over to see if I have missed
-- Jeff J.
On 10/22/2010 10:36 AM, Daniel Calcoen wrote:
> I'm compiling for Renesas RX with gcc 4.5 (Newlib 1.18.0)
> As RX floating point unit is 32bits the compiler defines double=float
> and DBL_DIG=FLT_DIG=6
> ( the following is exactly the same for strtod() )
> When I do a strof() for the string "1.17549434E-37"
> I end with the float 1.175494e-035, where the mantissa is ok but the
> exponent is wrong.
> following the code of strtod.c at line 442
> k = nd< DBL_DIG + 1 ? nd : DBL_DIG + 1;
> k is 7 (nd=9 and DBL_DIG=6)
> then goes to line 523
> e1 += nd - k;
> where e1 (-45) is adjusted to -43
> (the mantissa was converted correctly, rv.d=1.1754943e+8)
> then the approximation will end with 1.175494e-035 (instead of
> I don't understand all the details of the precision check and the
> approximation that follows so I looking for help to solve my problem.
> When I compile for double=64 bits and float=32bits so DBL_DIG=15 the results
> are correct.
> Daniel Calcoen
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the Newlib