René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Drop support for platforms without two's complement integer representation: require two's complement to build Python","articleBody":"Require [Two's complement](https://en.wikipedia.org/wiki/Two%27s_complement) to build Python.\r\n\r\nOnly very old machines (built in the 1960s?) like [UNIVAC 1100/2200 series](https://en.wikipedia.org/wiki/UNIVAC_1100/2200_series) use [signed number representations](https://en.wikipedia.org/wiki/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](https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html) to GCC and clang.\r\n\r\nThe *signed* parameter of ``int.from_bytes()`` and ``int.to_bytes()`` indicates whether two's complement is used to represent the integer.\r\n\r\nI propose to be more explicit on build requirements for integers:\r\n\r\n* Two's complement\r\n* No trap representation\r\n* No padding bits\r\n\r\nMark Dickinson @mdickinson likes to repeat that CPython has these requirements :-)\r\n\r\n* https://github.com/python/cpython/pull/27832#pullrequestreview-734243048\r\n\r\n\u003e 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.)\r\n\r\n* https://github.com/python/cpython/pull/17933#discussion_r674992923\r\n\r\n\u003e (...) 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` (...)\r\n\r\nI 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 \u003c= index \u0026\u0026 index \u003c limit`` (``Py_ssize_t``) with ``(size_t)index \u003c (size_t)limit``. I'm not sure that two's complement is strictly required for this micro-optimization, but it reminded it to me :-)\r\n\r\ncc @mdickinson\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-100009\n* gh-100014\n* gh-100045\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/vstinner","@type":"Person","name":"vstinner"},"datePublished":"2022-12-05T14:04:32.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":5},"url":"https://github.com/100008/cpython/issues/100008"}