Gah;  did I really misnumber that issue patch?  Sorry.

> Mark, did you write those rules down somewhere?

Well, they're all in the standard, which is publicly available.  (Or at least, a draft of the standard that's pretty much interchangeable with the real thing is publicly available;  Google for n1256.pdf, or see hyperlink [1] below.)

The correctness of the patch depends on:

(1) the 'usual arithmetic conversions', C99 6.3.1.8, paragraph 1.
     This implies that the other (uncast) long argument will be
     converted to unsigned long before the operation is performed.
    This part is safe.  When reading the rules, note that the 'long'
    and 'unsigned long' types have the same rank. (C99 6.3.1.1, 4th
    listed point.)

(2) an assumption that the C implementation will never raise an
    'implementation-defined' signal (C99 6.3.1.3p3).  This seems
    reasonable:  I'm fairly sure that this provision is there mainly
    for systems using ones' complement or sign-magnitude
    representations for signed integers, and it's safe to assume
    that Python won't meet such systems.

(3) an assumption that integer division for negative arguments
    follows C99 semantics, namely that the quotient is rounded
    towards zero.  C99 requires this (C99 6.5.5p6);  the older
    1989 standard allows quotients to be truncated either towards
    zero (like C99), or towards -infinity (like Python does).  In
    the presence of rounding towards -infinity, the style of
    overflow check used in int_pow can fail.  Even on C89 systems,
    truncation is much more common than flooring for this, so I
    think we're safe again here:  I don't know of any existing
    compilers with issues;  new/future compilers are likely to follow
    the C99 standard here.

[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf