[PATCH] Fix strtod for small DBL_DIG

[Steven Abner]

On May 16, 2011, at 8:33 AM, Corinna Vinschen wrote:

> On May 16 14:21, Christian Bruel wrote:
>> Hi Corinna,
>> 
>> Thanks for having testing it on cygwin32.
>> 
>> On 05/16/2011 01:36 PM, Corinna Vinschen wrote:
>>> This code always aborts because the value 12.345678 is not representable
>>> as 32 bit float value.  The same happens when using glibc as well.  If
>>> you print the float values with many digits, you get something like
>>> 
>>>  12.34567832946777 for DVal1 and
>>>  12.34567928314209 for dtmp.
>>> 
>>> on both, Cygwin/newlib and Linux/glibc.
>>> 
>>> Also, this does *not* change if I use your patch.
>>> 
>> 
>> Sorry, I was not clear about the original bug and what the patch was
>> fixing. It is not a precision problem, but really a magnitude
>> problem. So indeed my example fails for precision errors, but that
>> was not the original goal.
>> 
>> Please find attached the revisited test case that is will expose the
>> bug more precisely.
>> 
>> on the SH4 -m4-single-only GCC (which means doubles are 32 bit) I
>> get the values: 1.234568 12.345679 printed,
>> 
>> which is not a problem of representation problem, but a true conversion bug.
> 
> Thanks for the testcase.  However, I can still not reproduce the
> problem.  I tried again with float and strtof on Cygwin, but
> regardless of running it with or without your patch, it results
> in printing
> 
>  12.3456789 12.3456789
> 
> The strtod_r code is plain C so I'd expect that the conversion
> is target independent.  So why would it fail for arm but not for
> i386?
> 
> 
> Corinna
> 
> -- 
> Corinna Vinschen
> Cygwin Project Co-Leader
> Red Hat

A little off topic, but Corinna found bug in printf
default precision print out should be 6 digits...
but using two different source codes, I get using floats as
Corinna 12.345679 12.345679
could it be a printf problem instead?
i386 also

Steve