[Bug 14393] New: atoi() implemenation on large integers is wrong

http://bugs.winehq.org/show_bug.cgi?id=14393

Summary: atoi() implemenation on large integers is wrong
           Product: Wine
           Version: 1.1.0
          Platform: Other
        OS/Version: other
            Status: UNCONFIRMED
          Severity: minor
          Priority: P2
         Component: -unknown
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
                CC: [e-mail]

Created an attachment (id=14706)
 --> (http://bugs.winehq.org/attachment.cgi?id=14706)
demonstration of the wrong behaviour

This bug has been mentioned on the wine mailinglist:
http://www.winehq.org/pipermail/wine-devel/2004-May/027187.html

If you give atoi a string of an unsigned integer (>2^31) the wine
implementation gives a strange result (apparently alway the same integer).

The GNU-libc and the windows implementation gives the correct, unsigned
integer.

[Bug 14393] atoi() implemenation on large integers is wrong

http://bugs.winehq.org/show_bug.cgi?id=14393

--- Comment #1 from Lei Zhang   2008-07-15 18:17:14 ---
gcc produces the wrong result here:

$ uname -m
i686
$ gcc --version
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

$ gcc foo.c
$ ./a.out
127.255.255.255 2147483647

[Bug 14393] atoi() implemenation on large integers is wrong

http://bugs.winehq.org/show_bug.cgi?id=14393

--- Comment #2 from Joël Bohnes   2008-07-15 20:29:48 ---
Ok this is strange - it works on my 64bit systems but doesn't work on 32bit..
so you mustn't use atoi() on strings representing integers > INT_MAX.

Anyway, mingw&wine gives other results than mingw&windows - it may cause
hard-to-find bugs if applications rely on the windows-specific behaviour.

[Bug 14393] atoi() implemenation on large integers is wrong

http://bugs.winehq.org/show_bug.cgi?id=14393

--- Comment #3 from Lei Zhang   2008-07-17 16:50:42 ---
I compiled with gcc with cygwin on 32-bit Windows XP, and I get the same
results as 32-but Ubuntu. Are you testing on 64-bit Windows as well?

[Bug 14393] atoi() implemenation on large integers is wrong

http://bugs.winehq.org/show_bug.cgi?id=14393

--- Comment #4 from Joël Bohnes   2008-07-17 18:45:45 ---
Well that's why cygwin is there - to get the same results as under linux.
The executable you built uses glibc and therefore you get this result. Your
application won't run without cygwin, or at least, without the 'cygwin.dll'.

You can tell gcc that you don't want to build a cygwin exectuable but a native
windows appliction by adding the '-mno-cygwin' parameter.

So compile the source like this: 'gcc foo.c -mno-cygwin -lwsock32', run the
resulting exe and you'll see the difference.

[Bug 14393] atoi() implemenation on large integers is wrong

http://bugs.winehq.org/show_bug.cgi?id=14393

Lei Zhang  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1

--- Comment #5 from Lei Zhang   2008-07-18 19:27:56 ---
Right, patch sent:

http://article.gmane.org/gmane.comp.emulators.wine.patches/54466

[Bug 14393] atoi() implemenation on large integers is wrong

http://bugs.winehq.org/show_bug.cgi?id=14393

Lei Zhang  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #6 from Lei Zhang   2008-07-22 12:07:19 ---
Patch committed, marking this fixed.

http://www.winehq.org/pipermail/wine-cvs/2008-July/045681.html

[Bug 14393] atoi() implemenation on large integers is wrong

http://bugs.winehq.org/show_bug.cgi?id=14393

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #7 from Alexandre Julliard   2008-07-25 13:22:59 ---
Closing bugs fixed in 1.1.2.