[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