diff options
author | Tim Peters <tim.peters@gmail.com> | 2006-05-23 18:45:30 (GMT) |
---|---|---|
committer | Tim Peters <tim.peters@gmail.com> | 2006-05-23 18:45:30 (GMT) |
commit | b713ec2531b61568dd2e768455e37e160b578d76 (patch) | |
tree | dfa5a5ee0862bce5f0273040d4c5200c936a7fae /Lib/struct.py | |
parent | b63588c1881c350d209d389804dce4d8f5ca34d7 (diff) | |
download | cpython-b713ec2531b61568dd2e768455e37e160b578d76.zip cpython-b713ec2531b61568dd2e768455e37e160b578d76.tar.gz cpython-b713ec2531b61568dd2e768455e37e160b578d76.tar.bz2 |
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.
Diffstat (limited to 'Lib/struct.py')
0 files changed, 0 insertions, 0 deletions