[Tim Peters]
>> 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.
[Anthony Baxter]
> This should also be backported to release24-maint and release23-maint. Let me
>
"Tim Peters" <[EMAIL PROTECTED]> wrote:
>
> 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.
No, i
On Wednesday 30 August 2006 08:57, Tim Peters wrote:
> 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.
This should also be backported to release24-maint and release23-
On Wednesday 30 August 2006 08:57, Tim Peters wrote:
> 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.
Fine with me!
thanks,
Anthony
--
Anthony Baxter <[EMAIL P
[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).
[Ar
Hi Tim,
On Sat, Aug 26, 2006 at 08:37:46PM -0400, Tim Peters wrote:
> [Thomas Wouters]
> > Why not just "... && x == LONG_MIN"?
> 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 ma
[Anthony Baxter]
> Regardless of whether we consider gcc's behaviour to be correct or not,
It is correct, but more to the point it's, umm, /there/ ;-)
> I do agree we need a fix for this in 2.5 final. That should also be
> backported to
> release24-maint for the 2.4.4 release, and maybe release2
On Sunday 27 August 2006 05:06, Jack Howarth 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 pr
Jack Howarth wrote:
> I believe some of the others here might be interested in
> some other postings on the gcc mailing list regarding this issue
> (which weren't cross-posted here)...
>
> http://gcc.gnu.org/ml/gcc/2006-08/msg00516.html
> http://gcc.gnu.org/ml/gcc/2006-08/msg00517.html
>
> It
I believe some of the others here might be interested in
some other postings on the gcc mailing list regarding this issue
(which weren't cross-posted here)...
http://gcc.gnu.org/ml/gcc/2006-08/msg00516.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00517.html
It makes clear that the impact of this
[David Hopwood]
> (CPython has probably only been tested on 2's complement systems anyway,
Definitely so. Are there any boxes using 1's-comp or sign-magnitude
integers anymore? Python assumes 2's-comp in many places.
> but if we're going to be pedantic about depending only on things in the
> C
Thomas Wouters wrote:
> On 8/26/06, David Hopwood <[EMAIL PROTECTED]> wrote:
>
>> CPython should be fixed anyway. The correct fix is
>> "if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)".
>
> Why not just "... && x == LONG_MIN"?
Because the intent is to check that x / y does not ov
[David Hopwood]
>> CPython should be fixed anyway. The correct fix is
>> "if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)".
Note that this was already suggested in the bug report.
[Thomas Wouters]
> Why not just "... && x == LONG_MIN"?
In full,
if (y == -1 && x == LONG_MIN)
Jack Howarth wrote:
> Guido,
> You'll never win that argument with the gcc developers. If you
> rely on undefined behavior in the c language standard, they have
> in the past, and will continue to, feel free to ignore those cases.
> If you plan on ignoring this issue, just be prepared to see a
On 8/26/06, David Hopwood <[EMAIL PROTECTED]> wrote:
CPython should be fixed anyway. The correct fix is"if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)".Why not just "... && x == LONG_MIN"?
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature
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 a
Guido,
You'll never win that argument with the gcc developers. If you
rely on undefined behavior in the c language standard, they have
in the past, and will continue to, feel free to ignore those cases.
If you plan on ignoring this issue, just be prepared to see a
testcase failure in the pytho
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 pr
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
19 matches
Mail list logo
