[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 release23-maint, as Barry
> recently started talking about cutting a 2.3.6.
>
> Can I nominate Tim, with his terrifying knowledge of C compiler esoterica, as
> the person to pick the best fix?
It's a bitch. Changing to
if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)
is the obvious fix, but violates our "no warnings" policy: the MS
compiler warns about applying unary minus to an unsigned operand -- it
"looks insane" to /their/ compiler writers ;-). Elegant patch below
-- LOL.
Would be nice if someone verified it worked on a box where it matters.
Would also be nice if people checked to see whether their compiler(s)
warn about something else now.
IIndex: Objects/intobject.c
===================================================================
--- Objects/intobject.c (revision 51618)
+++ Objects/intobject.c (working copy)
@@ -564,8 +564,14 @@
"integer division or modulo by zero");
return DIVMOD_ERROR;
}
- /* (-sys.maxint-1)/-1 is the only overflow case. */
- if (y == -1 && x < 0 && x == -x)
+ /* (-sys.maxint-1)/-1 is the only overflow case. x is the most
+ * negative long iff x < 0 and, on a 2's-complement box, 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-".
+ */
+ if (y == -1 && x < 0 && (unsigned long)x == 0-(unsigned long)x)
return DIVMOD_OVERFLOW;
xdivy = x / y;
xmody = x - xdivy * y;