Re: [PATCH] Fix strtod for small DBL_DIG

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

On 05/16/2011 02:33 PM, 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?

Seems that the problem was reflected only when the number of digits 
after the decimal point was bigger that DBL_BIT for _DOUBLE_IS_32BIt 
architectures.

Looking at include/machine/ieeefp.h, only the mc68hc*,H83*, __xc16*, and 
SHs are impacted by the problem.

Now, for the other architectures, e.g the x86, ARM, having the hc, hf 
counts in the code reflect the number of processed digits, that can't be 
greater that DBL_BIT so I think my patch is the right thing to do. So 
DBL_BIT not really is a bound). Even though we don't see failures on 
those architectures

Best Regards

Christian

> Corinna