Guido van Rossum wrote:
On 8/26/06, Jack Howarth <howarth@bromo.msbb.uc.edu> wrote:
I discovered that gcc 4.2 exposes a flaw with signed integer overflows in python. This bug and the necessary fix has been discussed in detail on the gcc mailing list. I have filed a detailed bug report and the recommended patch proposed by the gcc developers. This problem should be addressed BEFORE python 2.5 is released. The bug report is...
[ 1545668 ] gcc trunk (4.2) exposes a signed integer overflows
in the python sourceforge bug tracker. Thanks in advance for attempting to fix this before Python 2.5 is released.
I'm not sure I follow why this isn't considered a regression in GCC. Clearly, on all current hardware, x == -x is also true for the most negative int (0x80000000 on a 32-bit box). Why is GCC attempting to break our code (and then blaming us for it!) by using the C standard's weaselwords that signed integer overflow is undefined, despite that it has had a traditional meaning on 2's complement hardware for many decades? If GCC starts to enforce everything that the C standard says is undefined then very few programs will still work...
+1. It's clearly undefined behaviour, but that doesn't mean that it is a good idea for gcc to be making changes that could silently break a lot of code, in pursuit of a microoptimization that is unlikely to significantly help performance. CPython should be fixed anyway. The correct fix is "if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)". -- David Hopwood <david.nospam.hopwood@blueyonder.co.uk>