Не получать Integer Overflow

Question

Скажем, я хочу напечатать некоторые значения. Я предполагаю, что я должен получить Integer Overflow, если моя подписанная переменная превышает от TMin и TMax (в этом случае, используя 4 байта int, 0x7FFFFFFF как Tmax и 0x80000000 как Tmin), но в этом примере я не получаю то, что ожидаю (объяснено в комментарии):

// Tmax = 0x7FFFFFFF == 2147483647 
// Tmin = 0x80000000 == -2147483648 
printf("1- overflow test: %d\n", 0x7FFFFFFF+1); // overflow - how compiler finds out it's a signed value, not an Unsigned one 
printf("2- overflow test: %d\n", 0x80000000-1); // in contrast, why I am not getting an integer overflow here 
printf("3- overflow test: %d\n", (int) 0x80000000-1); // overflow (Expected) 
printf("4- overflow test: %d\n",(int) (0x7FFFFFFF+1)); // overflow (Expected) 

Answer 1

ОП не всегда сталкивается с целым переполнением со знаком, что является неопределенным поведением.

Следующая математика без знака, так как 0x80000000, вероятно, является целым числом без знака. Шестнадцатеричные константы такого типа, который подходит им первого int, unsigned, long, unsigned long, ...

printf("2- overflow test: %d\n", 0x80000000-1); 

0x80000000-1 является беззнаковым типом как 0x80000000 первых припадков в беззнаковом типе, которые могут unsigned со значением 2147483648u. 2147483648u - 1 ->2147483647u.

0x7FFFFFFF+1 является знаковым типом, как 0x7FFFFFFF первых припадков в знаковом типе, вероятно int со значением INT_MAX.
int + int ->intиINT_MAX + 1 -> переполнение.

---

ОП сказал: «0x80000000 как Tmin», безусловно, является неправильным пониманием. В C, с 32-битным int/unsigned, 0x80000000 является шестнадцатеричной константой со значением 2147483648. Для ОП Тмин более вероятен -INT_MAX - 1.

Answer 2

Прежде всего, позвольте мне сказать вам, (подпись) целочисленное переполнение вызывает undefined behavior.

В этом случае все может произойти. Вы не можете ни доверять, ни обосновывать вывод кода с UB.

Просто для уточнения, даже

printf("2- overflow test: %d\n", 0x80000000-1); 

является UB. Хотя 0x80000000-1 - unsigned, а не переполнение само по себе, использование %d приведет к несоответствию типа, которое технически приведет к UB.

Что касается неопределенного поведения, от C11, приложение §J.2,

Преобразование в или из целого типа производит значение вне диапазона, который может быть представлен .

Answer 3

Попытка вызвать переполнение целых чисел - это неопределенное поведение. В соответствии со стандартом в этом случае может произойти что-либо, в том числе внешне непереполняющее. Какие результаты являются неинтересными и неактуальными.

Возможно, ваш компилятор оптимизирует его. Возможно, ваша система отказывается использоваться таким образом, возможно, что мешок риса, падающий в фарфор, вызвал эффект бабочки, который приводит к этому. Его ничего не определяло, что там происходит.

Возможно, ваша система решила, что ее целые числа больше. Только нижний предел целочисленных размеров (2 байта) задан в c (по крайней мере 4 типично для стандартных компьютеров). Ваша система может иметь 8 байтовых целых чисел или даже больше.

Answer 4

C является несовместимым с численными исключениями.

Есть несколько вещей, которые вы можете сделать, которые почти всегда вызывают проблемы. Если вы разделите на 0, ваша программа, как правило, будет сильно крутиться, как если бы вы обратились к недопустимому указателю.

Есть несколько вещей, которые вы можете сделать, которые гарантированно не вызовут проблемы. Если вы говорите,

unsigned int i = UINT_MAX; 

, а затем добавить к нему 1, это гарантировано, чтобы обернуть вокруг 0.

И есть целый ряд вещей, где поведение не определено или не определено. Однозначное переполнение целого числа. Строго говоря, это не определено (все может случиться, вы не можете зависеть от него). На практике большинство компьютеров спокойно обматывают, как и для арифметики без знака.

Теперь все, о чем я говорил, касается поведения программы во время выполнения, но в этом фрагменте кода этого вопроса все арифметические события происходят во время компиляции. Арифметика времени компиляции работает в основном по тем же правилам, что и время выполнения, но не всегда. Современные компиляторы, как правило, предупреждают вас о проблемной арифметике времени компиляции (моя копия gcc издает три предупреждения для опубликованного фрагмента), но не всегда.