Guido van Rossum wrote: > On 8/26/06, Jack Howarth <howarth at 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 at blueyonder.co.uk>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4