[Python-Dev] Drop support for ones' complement machines?
Mark Dickinson
dickinsm at gmail.com
Tue Dec 1 14:16:59 CET 2009
Question: should the CPython source compile cleanly and work
correctly on (mostly ancient or hypothetical) machines that use
ones' complement or sign-and-magnitude to represent signed integers?
I'd like to explicitly document and make use of the following assumptions
about the underlying C implementation for CPython. These assumptions
go beyond what's guaranteed by the various C and C++ standards, but
seem to be almost universally satisfied on modern machines:
- signed integers are represented using two's complement
- for signed integers the bit pattern 100....000 is not a trap representation;
hence INT_MIN = -INT_MAX-1, LONG_MIN = -LONG_MAX-1, etc.
- conversion from an unsigned type to a signed type wraps modulo
2**(width of unsigned type).
Any thoughts, comments or objections? This may seem academic
(and perhaps it is), but it affects the possible solutions to e.g.,
http://bugs.python.org/issue7406
The assumptions listed above are already tacitly used in various bits
of the CPython source (Objects/intobject.c notably makes use of the
first two assumptions in the implementations of int_and, int_or and
int_xor), while other bits of code make a special effort to *not* assume
more than the C standards allow. Whatever the answer to the initial
question is, it seems worth having an explicitly documented policy.
If we want Python's core source to remain 100% standards-compliant,
then int_and, int_or, etc. should be rewritten with ones' complement
and sign-and-magnitude machines in mind. That's certainly feasible,
but it seems silly to do such a rewrite without a good reason.
Python-dev agreement that ones' complement machines should be
supported would, of course, be a good reason.
Mark
More information about the Python-Dev
mailing list