[PATCH] Fix strtod for small DBL_DIG

Corinna Vinschen vinschen@redhat.com
Mon May 16 13:15:00 GMT 2011

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


Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

More information about the Newlib mailing list