Почему вы хотите, чтобы произошло целочисленное переполнение?

Основной момент, когда я хочу переполнения, — это вычисление хэш-кодов. Там фактическая числовая величина результата вообще не имеет значения - это фактически просто битовый шаблон, которым я манипулирую с помощью арифметических операций.

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

Я всегда думал, что переполнение вызывает неопределенное поведение и его следует предотвращать, где это возможно.

Вас также может смутить разница между переполнением буфера (переполнением) и числовым переполнением.

Переполнение буфера — это когда данные записываются за конец неуправляемого массива. Это может привести к неопределенному поведению, например к перезаписи адреса возврата в стеке введенными пользователем данными. Переполнение буфера сложно реализовать в управляемом коде.

Однако числовое переполнение четко определено. Например, если у вас есть 8-битный регистр, он может хранить только 2 ^ 8 значений (от 0 до 255, если без знака). Таким образом, если вы добавите 100+200, вы получите не 300, а 300 по модулю 256, что равно 44. С использованием знаковых типов история немного сложнее; битовый шаблон увеличивается аналогичным образом, но они интерпретируются как дополнение до двух, поэтому добавление двух положительных чисел может дать отрицательное число.

При выполнении вычислений с постоянно увеличивающимися счетчиками. Классический пример — Environment.TickCount:

int start = Environment.TickCount;
DoSomething();
int end = Environment.TickCount;
int executionTime = end - start;

Если бы это было проверено, программа имела бы шансы взорваться через 27 дней после загрузки Windows. Когда TickCount превышает значение int.MaxValue во время выполнения DoSomething. Еще одним примером является PerformanceCounter.

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

Углы

Целые числа, которые переполняются, являются элегантными инструментами для измерения углов. У вас есть 0 == 0 градусов, 0xFFFFFFFF == 359,999.... градусов. Это очень удобно, потому что как 32-битные целые числа вы можете добавлять/вычитать углы (350 градусов плюс 20 градусов заканчиваются переполнением, возвращаясь к 10 градусам). Также вы можете решить рассматривать 32-битное целое число как со знаком (от -180 до 180 градусов) и без знака (от 0 до 360). 0xFFFFFFFF соответствует -179,999..., что соответствует 359,999..., что эквивалентно. Очень элегантно.

При создании хэш-кодов, скажем, из строки символов.

почему бы вам всегда не предотвратить это, если у вас есть возможность?

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

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

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

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

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

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

Есть одна классическая история о программисте, который воспользовался переполнением при разработке программы:

История Мела

Это связано не столько с тем, как работают регистры, сколько с ограничениями памяти в переменных, в которых хранятся данные. (Вы можете переполнить переменную в памяти без переполнения каких-либо регистров.)

Но чтобы ответить на ваш вопрос, рассмотрим простейший тип контрольной суммы. Это просто сумма всех проверяемых данных. Если контрольная сумма переполняется, это нормально, и часть, которая не переполнилась, по-прежнему имеет смысл.

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

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

Целочисленное переполнение происходит следующим образом.

У вас есть 8-битное целое число 1111 1111, теперь добавьте к нему 1. 0000 0000, ведущая 1 усекается, так как она будет на 9-й позиции.

Теперь скажем, что у вас есть целое число со знаком, старший бит означает, что оно отрицательное. Итак, теперь у вас есть 0111 1111. Добавьте к нему 1, и вы получите 1000 0000, то есть -128. В этом случае добавление 1 к 127 привело к переключению на отрицательное значение.

Я совершенно уверен, что переполнение ведет себя определенным образом, но я не уверен насчет недополнения.

Вся целочисленная арифметика (ну хотя бы сложение, вычитание и умножение) является точной. Вам нужно быть осторожным только с интерпретацией полученных битов. В системе дополнения до 2 вы получаете правильный результат по модулю 2 на количество битов. Единственная разница между знаком и без знака заключается в том, что для чисел со знаком старший бит рассматривается как бит знака. Программист должен определить, что подходит. Очевидно, что для некоторых вычислений вы хотите знать о переполнении и предпринимать соответствующие действия, если оно обнаружено. Лично я никогда не нуждался в обнаружении переполнения. Я использую линейный конгруэнтный генератор случайных чисел, который опирается на него, то есть 64 * 64-битное целочисленное умножение без знака, меня интересуют только младшие 64 бита, я получаю операцию по модулю бесплатно из-за усечения.