Guido van Rossum wrote: > On 8/26/06, Jack Howarth <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
