Drop support for platforms without two's complement integer representation: require two's complement to build Python

[vstinner]

Require Two's complement to build Python.

Only very old machines (built in the 1960s?) like UNIVAC 1100/2200 series use signed number representations different than two's complement. Nowadays, all CPUs use the two's complement representation and CPython code base already relies on that in many places (especially Objects/longobject.c). For example, Python adds the -fwrapv compiler flag to GCC and clang.

The signed parameter of int.from_bytes() and int.to_bytes() indicates whether two's complement is used to represent the integer.

I propose to be more explicit on build requirements for integers:

• Two's complement
• No trap representation
• No padding bits

Mark Dickinson @mdickinson likes to repeat that CPython has these requirements :-)

• bpo-44946: Streamline operators and creation of ints for common case of single 'digit'. #27832 (review)

I think the -(x + 1) pattern came from days when we worried too much about alternative integer representations allowed by the C spec (sign-magnitude, ones' complement, two's complement with a trap representation, etc.). But since then other parts of the codebase have been happy to assume that all integer types are two's complement, no padding bits, no trap representation, so I think it's safe to do so here. (And your changes to the other bitwise operations already assume two's complement and no trap representation.)

• bpo-39277, pytime: Fix overflow check on double to int cast #17933 (comment)

(...) But making all our usual assumptions about integer representation (two's complement, no trap representation, no padding bits, etc.), -INT_MIN-1 is the same as INT_MAX (...)

I created this issue while reviewing PR #99762 which proposes to generalize a micro-optimization relying on a cast from an signed integer to an unsigned integer: replace 0 <= index && index < limit (Py_ssize_t) with (size_t)index < (size_t)limit. I'm not sure that two's complement is strictly required for this micro-optimization, but it reminded it to me :-)

cc @mdickinson

Linked PRs

• gh-100008: Document Python build requirements #100009
• gh-100008: Require Two's complement to build Python #100014
• gh-100008: VS 2017 is required since Python 3.11 #100045

[vstinner]

See also issue gh-91073 which required IEEE 754 support in Python 3.11.

[vstinner]

• No trap representation
• No padding bits

Article about that: https://trust-in-soft.com/blog/2016/06/16/trap-representations-and-padding-bits/

The _Bool type caused trouble with trap values in the past in the struct module. See the issue gh-83870:

• commit 472fc84
• commit 1ae9cde

Lib/test/test_buffer.py still contains the skip:

                # Casts to _Bool are undefined if the source contains values
                # other than 0 or 1.
                if char == "?":
                    continue

[vstinner]

A first shy PR which only requires two's complement, without mentioning trap representation or padding: PR #100014.

[vstinner]

In 2018, N2218: Signed Integers are Two’s Complement was proposed for the C language:

There is One True Representation for signed integers, and that representation is two’s complement.

I don't know the status of this spec: see P0907R4.

[vstinner]

See PR #100064 which casts a signed integer to an unsigned integer to test 0 <= value < limit as a single (size_t)value < limit operation.