> точно? точно-точно? а ну-ка, давай рассказывай, где какие. у каких процессоров int
> — не two's complement, сколько таких, и сколько процессоров, где two's complement?

Они по размеру разные. Могут быть - bмеют право. У одних чуваков вообще char был 16-битный. Не потому что они уникод любят, а потому что их DSP напрочь не умеет работать с отдельными байтами. Определения базовых типов в сях и работа с ними вообще странные и оставляют желать.

> при чём тут размеры инта? O_O

А том, что если уж докапываться до работы с числами, размерность стандартных типов и все что вокруг - достаточно популярный источник грабель. В том числе и ведущих к переполнениям. Вон какой-нибудь автор LZ4 по жизни юзает 64-битную платформу, а проблемы нег^W 32-битных платформ его взволновали только после наглого жирного CVE...

> ты чем читал вообще? unsigned int тоже не особо определён в точных размерах,

Именно int - да, всякие (u)intXX_t - уже более определенные, хотя и тоже несколько через ж, ибо могут быть как равны желаемому размеру, так и больше чем.

> но оговорить в стандарте поведение uint при переполнении это отчего-то
> никому не помешало.

Да это был как еще 1 пример бестолковостей с типами. Если там докапываться - там много к чему докопаться можно.

> и сколько их?

Не знаю. Процов много разных бывает, вплоть до самопалов на FPGA и академизвращений типа subleq.

> а инвалиды должны эмулировать фичи, которые есть у большинства.

Да вообще пожалуй валидный пойнт. Правда опять же - а как carry вывешивать, чтобы математика не тормознула в разы? В лучшем случае математика укладывается в 1 регистровую операцию, напрямую буквально. Посмотреть что в carry - минимум еще 1 операция на большинстве процов. Т.е. математику можно минимум в пару раз посадить. Был бы это дотнет - там бы наверное сделали. А тут ... кому сильно надо, аргументы может и сам проверить. И вопрос еще - хуже ли это чем всю математику по скорости убить в разы дополнительными проверками carry в каждом закоулке.