[Python-Dev] gcc 4.2 exposes signed integer overflows

David Hopwood david.nospam.hopwood at blueyonder.co.uk
Sun Aug 27 01:17:17 CEST 2006


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>




More information about the Python-Dev mailing list