Repository navigation
Drop support for platforms without two's complement integer representation: require two's complement to build Python #100008
Description
Activity
- added a commit that references this issue
on Dec 5, 2022 - 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:
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 == "?": continueIn 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.
- added a commit that references this issue
on Dec 6, 2022
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()andint.to_bytes()indicates whether two's complement is used to represent the integer.I propose to be more explicit on build requirements for integers:
Mark Dickinson @mdickinson likes to repeat that CPython has these requirements :-)
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