tree dfa5a5ee0862bce5f0273040d4c5200c936a7fae
parent b63588c1881c350d209d389804dce4d8f5ca34d7
author Tim Peters <tim.peters@gmail.com> 1148409930 +0000
committer Tim Peters <tim.peters@gmail.com> 1148409930 +0000
HG:extra convert_revision:svn%3A6015fed2-1504-0410-9fe1-9d1591cc4771/python/branches/legacy-trunk%4046133

Bug #1334662 / patch #1335972:  int(string, base) wrong answers.

In rare cases of strings specifying true values near sys.maxint,
and oddball bases (not decimal or a power of 2), int(string, base)
could deliver insane answers.  This repairs all such problems, and
also speeds string->int significantly.  On my box, here are %
speedups for decimal strings of various lengths:

length speedup
------ -------
 1       12.4%
 2       15.7%
 3       20.6%
 4       28.1%
 5       33.2%
 6       37.5%
 7       41.9%
 8       46.3%
 9       51.2%
10       19.5%
11       19.9%
12       23.9%
13       23.7%
14       23.3%
15       24.9%
16       25.3%
17       28.3%
18       27.9%
19       35.7%

Note that the difference between 9 and 10 is the difference between
short and long Python ints on a 32-bit box.  The patch doesn't
actually do anything to speed conversion to long:  the speedup is
due to detecting "unsigned long" overflow more quickly.

This is a bugfix candidate, but it's a non-trivial patch and it
would be painful to separate the "bug fix" from the "speed up" parts.