bug in atof

[Louis. Lenders]

Hi, i filed a bug ( bug 4337) and looks like there's a
bug in atof. Is there a difference between linux' atof
and msvcrt's one? Even following simple program (from
msdn) yields wrong results:
// crt_atof.c
#include <stdlib.h>
#include <stdio.h>

int main( void )
{
   char *s; double x; int i; long l;

s = "  -2309.12E-15";    /* Test of atof */
   x = atof( s );
   printf( "atof test: "%s"; float:  %e\n", s, x );

s = "7.8912654773d210";  /* Test of atof */
   x = atof( s );
   printf( "atof test: "%s"; float:  %e\n", s, x );

s = "  -9885 pigs";      /* Test of atoi */
   i = atoi( s );
   printf( "atoi test: "%s"; integer: %d\n", s, i );

s = "98854 dollars";     /* Test of atol */
   l = atol( s );
   printf( "atol test: "%s"; long: %ld\n", s, l );
}
the exponent value in float x are wrong. Thanks

___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

[Uwe Bonnes]

> > > > > "Louis" == Louis Lenders  writes:

Louis> Hi, i filed a bug ( bug 4337) and looks like there's a bug in
    Louis> atof. Is there a difference between linux' atof and msvcrt's one?
    Louis> Even following simple program (from msdn) yields wrong results:
    Louis> // crt_atof.c #include <stdlib.h> #include <stdio.h>

Louis> int main( void ) { char *s; double x; int i; long l;

Louis>    s = " -2309.12E-15"; /* Test of atof */ x = atof( s ); printf(
    Louis> "atof test: "%s"; float: %e\n", s, x );

Louis>    s = "7.8912654773d210"; /* Test of atof */ x = atof( s );
    Louis> printf( "atof test: "%s"; float: %e\n", s, x );

Louis>    s = " -9885 pigs"; /* Test of atoi */ i = atoi( s ); printf(
    Louis> "atoi test: "%s"; integer: %d\n", s, i );

Louis>    s = "98854 dollars"; /* Test of atol */ l = atol( s ); printf(
    Louis> "atol test: "%s"; long: %ld\n", s, l ); } the exponent value in
    Louis> float x are wrong. Thanks

Not atof() is the cause of your bug, but printf(). 
I entered your sample into the test suite to show the correct behaviour of
wine's implementation of atof. The printf() test has already a todo for the
incorrect exponent output.

[Peter Beutner]

Uwe Bonnes schrieb:
> > > > > > "Louis" == Louis Lenders  writes:
> Louis> Hi, i filed a bug ( bug 4337) and looks like there's a bug in
> Louis> atof. Is there a difference between linux' atof and msvcrt's one?
> Louis> Even following simple program (from msdn) yields wrong results:
> Louis> // crt_atof.c #include <stdlib.h> #include <stdio.h>
>
> Louis> int main( void ) { char *s; double x; int i; long l;
>
> Louis>    s = " -2309.12E-15"; /* Test of atof */ x = atof( s ); printf(
> Louis> "atof test: \"%s\"; float: %e\n", s, x );
>
> Louis>    s = "7.8912654773d210"; /* Test of atof */ x = atof( s );
> Louis> printf( "atof test: \"%s\"; float: %e\n", s, x );
>
> Louis>    s = " -9885 pigs"; /* Test of atoi */ i = atoi( s ); printf(
> Louis> "atoi test: \"%s\"; integer: %d\n", s, i );
>
> Louis>    s = "98854 dollars"; /* Test of atol */ l = atol( s ); printf(
> Louis> "atol test: \"%s\"; long: %ld\n", s, l ); } the exponent value in
> Louis> float x are wrong. Thanks
>
>
> Not atof() is the cause of your bug, but printf(). 
> I entered your sample into the test suite to show the correct behaviour of
> wine's implementation of atof. The printf() test has already a todo for the
> incorrect exponent output.

quoted from msdn[1]:
---
The string argument to atof and _wtof has the following form:

[whitespace] [sign] [digits] [.digits] [ {d | D | e | E }[sign]digits
---

Which means that '7.8912654773d210' is the same as '7.8912654773e210'.

But on linux we have(quoted from 'man strtod'):
-----
A decimal number consists of a nonempty sequence of decimal digits pos-
sibly  containing  a  radix character (decimal point, locale dependent,
usually ``.''), optionally followed by a decimal exponent.   A  decimal
exponent consists of an ``E'' or ``e'', followed by an optional plus or
minus sign, followed by a non-empty sequence  of  decimal  digits,  and
indicates multiplication by a power of 10.
----

It doesn't parse 'd' or 'D' as exponent.
Seems to be a "MS-only extension" to the standard :p

[1]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/...

[Uwe Bonnes]

> > > > > "Peter" == Peter Beutner  writes:

Peter> Which means that '7.8912654773d210' is the same as
    Peter> '7.8912654773e210'.

Running the test with native msvcrt doesn't give me 7.8912654773e210
neither...

Peter> But on linux we have(quoted from 'man strtod'): ----- A decimal
    Peter> number consists of a nonempty sequence of decimal digits pos-
    Peter> sibly containing a radix character (decimal point, locale
    Peter> dependent, usually ``.''), optionally followed by a decimal
    Peter> exponent.  A decimal exponent consists of an ``E'' or ``e'',
    Peter> followed by an optional plus or minus sign, followed by a
    Peter> non-empty sequence of decimal digits, and indicates
    Peter> multiplication by a power of 10.  ----

Peter> It doesn't parse 'd' or 'D' as exponent.  Seems to be a "MS-only
    Peter> extension" to the standard :p

Could you please check  '7.8912654773d210' gives the expected result on
windows?

Peter> [1]
    Peter> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/...

[Peter Beutner]

Uwe Bonnes schrieb:
> > > > > > "Peter" == Peter Beutner  writes:
> Peter> Which means that '7.8912654773d210' is the same as
> Peter> '7.8912654773e210'.
>
> Running the test with native msvcrt doesn't give me 7.8912654773e210
> neither...

Using the test that Louis posted in his first email ...

peter@lappy ~/coding $ /opt/xmingw/bin/i386-mingw32msvc-gcc -o test_atof.exe test_atof.c

peter@lappy ~/coding $ WINEDLLOVERRIDES=msvcrt=b  wine test_atof.exe
atof test: "  -2309.12E-15"; float:  -2.309120e-12
atof test: "7.8912654773d210"; float:  7.891265e+00
atoi test: "  -9885 pigs"; integer: -9885
atol test: "98854 dollars"; long: 98854

peter@lappy ~/coding $ WINEDLLOVERRIDES=msvcrt=n  wine test_atof.exe
atof test: "  -2309.12E-15"; float:  -2.309120e-012
atof test: "7.8912654773d210"; float:  7.891265e+210
atoi test: "  -9885 pigs"; integer: -9885
atol test: "98854 dollars"; long: 98854

So it works here as expected.
> Peter> But on linux we have(quoted from 'man strtod'): ----- A decimal
> Peter> number consists of a nonempty sequence of decimal digits pos-
> Peter> sibly containing a radix character (decimal point, locale
> Peter> dependent, usually ``.''), optionally followed by a decimal
> Peter> exponent.  A decimal exponent consists of an ``E'' or ``e'',
> Peter> followed by an optional plus or minus sign, followed by a
> Peter> non-empty sequence of decimal digits, and indicates
> Peter> multiplication by a power of 10.  ----
>
> Peter> It doesn't parse 'd' or 'D' as exponent.  Seems to be a "MS-only
> Peter> extension" to the standard :p
>
> Could you please check  '7.8912654773d210' gives the expected result on
> windows?

Hmm don't have any installed windows around here atm.But isn't it enough that the native
msvcrt gives the expected result?

[Uwe Bonnes]

> > > > > "Peter" == Peter Beutner  writes:

Peter> Uwe Bonnes schrieb:
    >>>>>>> "Peter" == Peter Beutner  writes:
    >>
    Peter> Which means that '7.8912654773d210' is the same as
    Peter> '7.8912654773e210'.
    >>  Running the test with native msvcrt doesn't give me 7.8912654773e210
    >> neither...
The test linked  libc atof and not msvcrt atof. I don't know if this is a
bug in our headers or something else. I will post a corrected patch for the
test suite ...

[Louis Lenders]

Uwe Bonnes <bon <at> elektron.ikp.physik.tu-darmstadt.de> writes:
> > > > > > "Peter" == Peter Beutner <p.beutner <at> gmx.net> writes:
> Peter> Uwe Bonnes schrieb:
> >>>>>>> "Peter" == Peter Beutner <p.beutner <at> gmx.net> writes:
> >>
> Peter> Which means that '7.8912654773d210' is the same as
> Peter> '7.8912654773e210'.
> >>  Running the test with native msvcrt doesn't give me 7.8912654773e210
> >> neither...
>
> The test linked  libc atof and not msvcrt atof. I don't know if this is a
> bug in our headers or something else. I will post a corrected patch for the
> test suite ...

Hi, looks like bug 4337 wasn't really related to the bug in the simple test app
i submitted (Hey , i'm just a poor debugging noob :) ). Bug 4337 is already
fixed by a patch from Julliard (thx) ) Should i file a bug report for the bug in
the simple test app (ripped from from msdn) or is it a known problem?

[Uwe Bonnes]

> > > > > "Louis" == Louis Lenders  writes:

Louis> Uwe Bonnes <bon <at> elektron.ikp.physik.tu-darmstadt.de> writes:
    >>  >>>>> "Peter" == Peter Beutner <p.beutner <at> gmx.net> writes:
    >> 
    Peter> Uwe Bonnes schrieb:
    >> >>>>>>> "Peter" == Peter Beutner <p.beutner <at> gmx.net> writes:
    >> >>
    Peter> Which means that '7.8912654773d210' is the same as
    Peter> '7.8912654773e210'.
    >> >> Running the test with native msvcrt doesn't give me
    >> 7.8912654773e210 >> neither...  The test linked libc atof and not
    >> msvcrt atof. I don't know if this is a bug in our headers or
    >> something else. I will post a corrected patch for the test suite ...

Louis> Hi, looks like bug 4337 wasn't really related to the bug in the
    Louis> simple test app i submitted (Hey , i'm just a poor debugging noob
    Louis> :) ). Bug 4337 is already fixed by a patch from Julliard (thx) )
    Louis> Should i file a bug report for the bug in the simple test app
    Louis> (ripped from from msdn) or is it a known problem?

It's now a know problem. I will try ti fix..

[Tobias Burnus]

Hello,

Peter Beutner schrieb:
> It doesn't parse 'd' or 'D' as exponent.
> Seems to be a "MS-only extension" to the standard :p

I would guess this comes from Fortran. Real values are printed with "e",
those with double precision printed with "d". And as one usually uses
double precision in Fortran, one ends up with several data files with
"d" instead of "e" as exponent.

Tobias

PS: I think it is a stupid idea, but as - an excuse - Fortran is quite
old (and even worked with punched cards).