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 <[EMAIL PROTECTED]> <http://bugs.python.org/issue1621> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com