[Python-Dev] gcc 4.2 exposes signed integer overflows

[Tim Peters]

[Thomas Wouters]
>>> Why not just "... && x == LONG_MIN"?

[Tim Peters]
>> it's better (when possible) not to tie the code to that `x` was
>> specifically declared as type "long" (e.g., just more stuff that will
>> break if Python decides to make its short int of type PY_LONG_LONG
>> instead).

[Armin Rigo]
> The proposed "correct fix" breaks this goal too:
>
> > >> "if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)".
>
>                                ^^^^^^^^^^^^^        ^^^^^^^^^^^^^

Yup, although as noted before the proposed fix actually writes

    == 0-(unsigned long)x

at the tail end instead (to avoid compiler warnings at least under MS C).

It doesn't run afoul of the other criterion you snipped from the start
of the quoted paragraph:

    In practice we try to avoid numeric symbols from platform header files
    because so many platforms have screwed these up over the centuries
    (search for LONG_BIT or HUGE_VAL ;-)), ....

This is a wrong time in the release process to take on chance on
discovering a flaky LONG_MIN on some box, so I want to keep the code
as much as possible like what's already there (which worked fine for >
10 years on all known boxes) for now.

Speaking of which, I saw no feedback on the proposed patch in

    http://mail.python.org/pipermail/python-dev/2006-August/068502.html

so I'll just check that in tomorrow.