[issue1621] Do not assume signed integer overflow behavior
Guido van Rossum
report at bugs.python.org
Fri Jan 18 02:22:44 CET 2008
Guido van Rossum added the comment:
I think the -Wstrict-overflow option may not be enough for the audit we
need.
The overflow issue in expandtabs() still exists (in 2.5 as well as in
the trunk):
if (*p == '\n' || *p == '\r') {
i += j;
old_j = j = 0;
if (i < 0) {
PyErr_SetString(PyExc_OverflowError,
"new string is too long");
return NULL;
}
}
Here i and j are signed ints (Py_ssize_t) initially know to be >= 0; i
can only become < 0 through overflow. This is the place where Ismail
(cartman) found a crash because the test was optimized away by GCC 4.3
before we added -fwrap.
If we ever hope to clean up the code to the point where -fwrapv is no
longer needed, the audit should find this spot! (Good thing we at least
had a unittest for the overflow check. This should be standard practice
for all overflow checks, as long it doesn't require allocating a GB or
more of memory.)
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
__________________________________
More information about the Python-bugs-list
mailing list