This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH] Fix strtod for small DBL_DIG
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