Mark Dickinson <dicki...@gmail.com> added the comment:
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
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12973>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
