Christian Heimes added the comment:
Python 2 is no longer supported. Python 3's _PyLong_Add() function doesn't rely
on overflow.
--
nosy: +christian.heimes
resolution: -> out of date
stage: needs patch -> resolved
status: open -> closed
___
Kevin Shweh added the comment:
It looks like the fast paths for INPLACE_ADD and INPLACE_SUBTRACT in Python 2
don't have the cast-to-unsigned fix, so they're still relying on undefined
behavior. For example, in INPLACE_ADD:
/* INLINE: int + int */
register long
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7406
___
___
Python-bugs-list
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +serhiy.storchaka, skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7406
___
___
Terry J. Reedy tjre...@udel.edu added the comment:
Thanks Tim. I see that is back in 3.2 rather than in the shift and mask
sections. At least I know what to refer to now.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7406
Changes by Gregory P. Smith g...@krypto.org:
--
nosy: +gregory.p.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7406
___
___
Python-bugs-list
Mark Dickinson dicki...@gmail.com added the comment:
Zooko: Yes; that's the sort of solution that's needed if we're not
allowed to assume two's complement with the extraordinary value (-
sys.maxint - 1) not a trap representation. If we are allowed to
assume this, then more efficient solutions
Terry J. Reedy tjre...@udel.edu added the comment:
I consider the binary bitwise operations, for negative ints, to be
either undefined or wrongly implemented. Consider the following (3.1)
3^2
1
-3^2
-1
3^-2
-3
-3^-2
3
2^3
1
-2^3
-3
Something change sign just flips the sign of the result,
Tim Peters tim.pet...@gmail.com added the comment:
Terry, the language reference also says:
For the purpose of shift and mask operations, a binary representation is
assumed, and negative numbers are represented in a variant of 2's
complement which gives the illusion of an infinite string of
Zooko O'Whielacronx zo...@zooko.com added the comment:
Here is a way to test for overflow which is correct for any C implementation:
static PyObject *
int_add(PyIntObject *v, PyIntObject *w)
{
register long a, b;
CONVERT_TO_LONG(v, a);
CONVERT_TO_LONG(w, b);
if
Zooko O'Whielacronx zo...@zooko.com added the comment:
Here is a set of macros that I use to test for overflow:
http://allmydata.org/trac/libzutil/browser/libzutil/zutilimp.h
--
___
Python tracker rep...@bugs.python.org
Mark Dickinson dicki...@gmail.com added the comment:
Fixed int_sub, int_add, int_mul, and the fast paths for BINARY_ADD and
BINARY_SUB in ceval.c, in r76629 (trunk) and r76630 (release26-maint).
--
___
Python tracker rep...@bugs.python.org
Changes by Eric Smith e...@trueblade.com:
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7406
___
___
Python-bugs-list mailing
New submission from Mark Dickinson dicki...@gmail.com:
Much of the code in Objects/intobject.c assumes that an arithmetic
operation on signed longs will wrap modulo 2**(bits_in_long) on
overflow. However, signed overflow causes undefined behaviour according
to the C standards (e.g., C99 6.5,
14 matches
Mail list logo
