summaryrefslogtreecommitdiffstats
path: root/Objects/intobject.c
diff options
context:
space:
mode:
authorArmin Rigo <arigo@tunes.org>2006-10-04 12:17:45 (GMT)
committerArmin Rigo <arigo@tunes.org>2006-10-04 12:17:45 (GMT)
commit7ccbca93a27e22f0b06316b0d9760fbf7b19cbda (patch)
tree63a92638c4b4faa7bcd2979eadeef5aa33a1abd9 /Objects/intobject.c
parent0d2f498a4cebb428a28fdc54b277ecede5ebc1c7 (diff)
downloadcpython-7ccbca93a27e22f0b06316b0d9760fbf7b19cbda.zip
cpython-7ccbca93a27e22f0b06316b0d9760fbf7b19cbda.tar.gz
cpython-7ccbca93a27e22f0b06316b0d9760fbf7b19cbda.tar.bz2
Forward-port of r52136,52138: a review of overflow-detecting code.
* unified the way intobject, longobject and mystrtoul handle values around -sys.maxint-1. * in general, trying to entierely avoid overflows in any computation involving signed ints or longs is extremely involved. Fixed a few simple cases where a compiler might be too clever (but that's all guesswork). * more overflow checks against bad data in marshal.c. * 2.5 specific: fixed a number of places that were still confusing int and Py_ssize_t. Some of them could potentially have caused "real-world" breakage. * list.pop(x): fixing overflow issues on x was messy. I just reverted to PyArg_ParseTuple("n"), which does the right thing. (An obscure test was trying to give a Decimal to list.pop()... doesn't make sense any more IMHO) * trying to write a few tests...
Diffstat (limited to 'Objects/intobject.c')
-rw-r--r--Objects/intobject.c16
1 files changed, 14 insertions, 2 deletions
diff --git a/Objects/intobject.c b/Objects/intobject.c
index 4e1f04f..a4d50be 100644
--- a/Objects/intobject.c
+++ b/Objects/intobject.c
@@ -546,6 +546,17 @@ int_mul(PyObject *v, PyObject *w)
}
}
+/* Integer overflow checking for unary negation: on a 2's-complement
+ * box, -x overflows iff x is the most negative long. In this case we
+ * get -x == x. However, -x is undefined (by C) if x /is/ the most
+ * negative long (it's a signed overflow case), and some compilers care.
+ * So we cast x to unsigned long first. However, then other compilers
+ * warn about applying unary minus to an unsigned operand. Hence the
+ * weird "0-".
+ */
+#define UNARY_NEG_WOULD_OVERFLOW(x) \
+ ((x) < 0 && (unsigned long)(x) == 0-(unsigned long)(x))
+
/* Return type of i_divmod */
enum divmod_result {
DIVMOD_OK, /* Correct result */
@@ -565,7 +576,7 @@ i_divmod(register long x, register long y,
return DIVMOD_ERROR;
}
/* (-sys.maxint-1)/-1 is the only overflow case. */
- if (y == -1 && x == LONG_MIN)
+ if (y == -1 && UNARY_NEG_WOULD_OVERFLOW(x))
return DIVMOD_OVERFLOW;
xdivy = x / y;
xmody = x - xdivy * y;
@@ -756,7 +767,8 @@ int_neg(PyIntObject *v)
{
register long a;
a = v->ob_ival;
- if (a < 0 && (unsigned long)a == 0-(unsigned long)a) {
+ /* check for overflow */
+ if (UNARY_NEG_WOULD_OVERFLOW(a)) {
PyObject *o = PyLong_FromLong(a);
if (o != NULL) {
PyObject *result = PyNumber_Negative(o);