This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]