[Python-Dev] Drop support for ones' complement machines?

Mark Dickinson dickinsm at gmail.com
Tue Dec 1 18:22:35 CET 2009

On Tue, Dec 1, 2009 at 4:47 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
>> On Tue, Dec 1, 2009 at 4:17 PM, James Y Knight <foom at fuhm.net> wrote:
>>> I think all that needs to be defined is that conversion from unsigned to signed, and (negative) signed to
>>>  unsigned integers have 2's complement wrapping semantics, and does not affect the bit pattern in memory.
> I don't know if this particular implementation defined behavior is
> safe to be relied upon. I just want to suggest that if any such
> assumption is made in the code, a test should be added to configure to
> complain loudly if a platform violating the assumption is found in the
> future.

That sounds like a good idea.  An extension of that would be to define
an UNSIGNED_TO_SIGNED macro (insert better name here) which,
depending on the result of the configure test, either used a direct cast
or a workaround.  E.g., for an unsigned long x,

  ((x) >= 0 ? (long)(x) : ~(long)~(x))

always gives the appropriate wraparound semantics (I think), assuming
two's complement with no trap representation.


More information about the Python-Dev mailing list