Re: [PATCH] Fix strtod for small DBL_DIG

[Christian Bruel <christian dot bruel at st dot com>]

On 05/16/2011 02:59 PM, Steven Abner wrote:
> 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

I think it's another problem, I can reproduce the bug without printf 
(which was in the example only for clarity, not necessary). And it's not 
about a wrong precision, but an order of magnitude since the decimal 
point was at the wrong place.

Cheers

Christian

> Steve