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

"Martin v. Löwis" martin at v.loewis.de
Tue Dec 1 16:32:12 CET 2009

> No, the original question really was the question that I meant to ask.  :)

Ok. Then the reference to issue 7406 is really confusing, as this is
about undefined behavior - why does the answer to your question affect
the resolution of this issue?

> I absolutely agree that CPython shouldn't invoke undefined behaviour,
> precisely because of the risk of gcc (or some other compiler)
> optimizing based on the assumption that undefined behaviour never
> happens.  This is why I opened issue 7406.
> So my question, and the listed assumptions, are about implementation-
> defined behaviour, not undefined behaviour.  For the 3 assumptions listed,
> gcc obeys all those assumptions (see section 4.5 of the GCC manual).
> http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Integers-implementation.html

I think gcc makes promises here beyond resolving implementation-defined
behavior. For bitshift operators, C99 says (6.5.7)

       [#4] The result of E1  <<  E2  is  E1  left-shifted  E2  bit
       positions; vacated bits are filled with zeros.  If E1 has an
       unsigned type, the value of the result  is  E1×2E2,  reduced
       modulo  one more than the maximum value representable in the
       result type.  If E1 has a signed type and nonnegative value,
       and E1×2E2 is representable in the result type, then that is
       the resulting value; otherwise, the behavior is undefined.

       [#5] The result of E1 >>  E2  is  E1  right-shifted  E2  bit
       positions.  If E1 has an unsigned type or if E1 has a signed
       type and a nonnegative value, the value of the result is the
       integral part of the quotient of E1 divided by the quantity,
       2 raised to the power E2.  If E1 has a  signed  type  and  a
       negative  value,  the  resulting  value  is  implementation-

Notice that only right-shift is implementation-defined. The left-shift
of a negative value invokes undefined behavior, even though gcc
guarantees that the sign bit will shift out the way it would under
two's complement.

So I'm still opposed to codifying your assumptions if that would mean
that CPython could now start relying on left-shift to behave in a
certain way. For right-shift, your assumptions won't help for
speculation about the result: I think it's realistic that some
implementations sign-extend, yet others perform the shift unsigned
(i.e. zero-extend).

I'd rather prefer to explicitly list what CPython assumes about the
outcome of specific operations. If this is just about &, |, ^, and ~,
then its fine with me.


More information about the Python-Dev mailing list