[PATCH] Fix strtod for small DBL_DIG

[Christian Bruel]

Hi Corinna,

Thanks for having testing it on cygwin32.

On 05/16/2011 01:36 PM, Corinna Vinschen wrote:
> Hi Christian,
>
> On May 12 14:26, Christian Bruel wrote:
>> Hello,
>>
>> This fixes a Plummhall ch7_1961B test failure discovered on SH4 GCC
>> for -m4-single-only mode (doubles as 32 bit floats) on sscanf.
>>
>> It is better illustrated with the attached reduced test case. The
>> problem turned out to be the digit counts in _strtod_ that are
>> incremented to much beyond DBL_DIG.
>>
>> The attached patch fixes this problem by updating the counts after
>> the DBL_DIG checks.
>> [...]
>> #include<stdlib.h>
>>
>> double Dval1 = 12.345678;
>>
>> main()
>> {
>>    double dtmp;
>>    char *buf;	
>>    dtmp = strtod ("12.3456789",&buf);
>>
>>    if (dtmp != Dval1)
>>      abort();
>>
>>    return 0;
>>
>> }
>
> For testing I changed double to float and strtod to strtof to get a 32
> bit value on 32 bit Cygwin and 64 bit Linux.
>
> 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.

Best Regards

Christian


>
> Corinna
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: a.c
URL: <http://sourceware.org/pipermail/newlib/attachments/20110516/194abef7/attachment.c>