Приведение signed int к unsigned int?

Question

[maxim_01]

Почему при бинарной операции операндов: signed int и unsigned int - первый операнд приводится к unsigned int?

Answer 1

[Mercury13]

Видимо, связано с авариями переполнения. Представьте себе такую штуку: −128 + 255 = 127. Если в процессоре будут аппаратные аварии переполнения, это самое переполнение и произойдёт: −128 − 1 = ???. Беззнаковый тип аварий переполнения не вызывает.

UPD. Так и есть. В Си знаковое переполнение — UB: такое переполнение может разделить с остатком, вызвать аварию или упереться в границы. В GCC есть ключи -ftrapv и -fwrapv — что делать при таком пререполнении.
Беззнаковое — обязательно деление с остатком.

UPD2. Стандарты Си и LIA несколько противоречат друг другу, и можно предположить, что знаковое переполнение зависит от реализации. Это не UB — можно сделать хороший код, полагающийся на такое поведение. Но если x86 так поступает, то не обязательно, что так поступают все.

Comments

[maxim_01]

Да тут никакой я аварии не вижу! Представим числа которые вы привели более малым типом char signed. Ну так вот −128 − 1 = 127. Все просто, я это даже протестировал.

[Mercury13]

−128 − 1 = −129, если ты не на компьютере считал, а учился в школе!
А 127 — это последствия арифметического переполнения.

На x86 отрицательные числа реализованы дополнительным кодом, это приводит к тому, что знаковый плюс и беззнаковый плюс — одна и та же операция. Плюс проверка арифметических переполнений требует телодвижений каждый раз, когда складываем-вычитаем (операции jc/jnc, jo/jno) — так что никто эти переполнения не проверяет.

Я полагаю, что это связано с машинами, где авария арифметического переполнения реализована менее накладным способом. Например, через прерывания, как деление на ноль в x86.

[Mercury13]

Ну разумеется, одним байтом я это написал только для наглядности. По правилам языка арифметика идёт как минимум в int…

[maxim_01]

Mercury13: да идет в int, но даже если проделать то что я написал выше, и с int результат будет такой же. То есть после максимального значения у int будет минимальное значение int. Но и где же авария? Это типичное переполнение типа!

[Mercury13]

maxim_01: Компиляторы под x86 не реализуют аварий, и им, извини, похрѣнъ. Си появился за пять лет до 86-х процессоров.
Авария — это когда программа отходит от своего нормального хода при переполнении — через прерывание, сигнал, исключение или что-нибудь ещё.

[Mercury13]

Я тут загуглил и нашёл.
В Си знаковое переполнение — UB, беззнаковое — деление с остатком.

[Mercury13]

А в GCC есть ключи -ftrapv и -fwrapv.

[maxim_01]

Mercury13: дайте почитать что вы там загуглили =) И да тогда скажите мне почему из двух signed int и unsigned int, победа будет на стороне unsigned int (то есть один тип будет приведен к другому типу при выполнении какой-либо арифметической операции)?

[Mercury13]

Стандарт Си, 3.4.3.1. «An example of undefined behavior is the behavior on integer overflow».
Стандарт LIA, 5.1.1.1. For integer operations, this document does not specify continuation values for overflow when hasinf_I = false nor the continuation values for invalid. The binding or implementation must document the continuation value(s) used for such cases (see Clause 8)

[Mercury13]

И да тогда скажите мне почему из двух signed int и unsigned int, победа будет на стороне unsigned int (то есть один тип будет приведен к другому типу при выполнении какой-либо арифметической операции)?

Таков уж стандарт. Как только появляется unsigned, все дальнейшие результаты unsigned.

[Mercury13]

maxim_01: Кроме того, компилятор не устраивает голосование, каких больше, знаковых или беззнаковых, а просто выполняет операцию за операцией.