Почему в C и C++ нет встроенных способов проверки целочисленного переполнения?

C и C++ следуют основному принципу «Вы не платите за то, что вам не нужно». Таким образом, арифметические операции по умолчанию не будут отклоняться от единственной инструкции базовой архитектуры для арифметических операций.

Что касается того, почему нет стандартной библиотечной функции для сложения двух целых чисел и обнаружения переполнения, я не могу сказать. Во-первых, кажется, что язык определяет переполнение целых чисел со знаком как неопределенное поведение:

В языке программирования C переполнение целого числа со знаком приводит к неопределенному поведению.

Учитывая, что существует несколько способов реализации целого числа со знаком (дополнение до единицы, дополнение до двух и т. д.), и когда был создан C, все эти архитектуры были распространены, понятно, почему это не определено. Было бы сложно реализовать «безопасную*» функцию чистого C без большого количества информации о базовой платформе. Это можно было бы сделать, зная процессор за процессором.

Тем не менее, это не делает это невозможным. Мне определенно было бы интересно, если бы кто-нибудь мог найти предложения органам по стандартизации C или C++ с более безопасными помощниками переполнения и смог бы понять, почему они были отклонены.

Несмотря на это, на практике существует множество способов обнаружения арифметических переполнений. и библиотеки в помощь.

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

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

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

Вопрос всплывает регулярно.

Во-первых, помните, что C определяется как портативный и эффективный. Таким образом, он был разработан только для обеспечения операций, которые поддерживались множеством оборудования (вероятно, еще до того, как x86 увидел свет).

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

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

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

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

Целочисленное переполнение — это UB, потому что вы редко заботитесь об этом. Если мой unsigned char переполняется во время операций, возможно, я выбрал неправильный тип для накопления 10 миллионов чисел. Но знание о переполнении во время выполнения мне не поможет, так как мой дизайн все равно сломан.

Лучше задать вопрос: почему целочисленное переполнение не определено? На практике 99,9% всех процессоров используют дополнение до двух и бит переноса/переполнения. Таким образом, в реальном мире, на уровне ассемблера/кода операции, целочисленные переполнения всегда четко определены. На самом деле большая часть ассемблера или аппаратного языка C в значительной степени зависит от четко определенных целочисленных переполнений (в частности, драйверов для оборудования таймера).

Исходный язык C до стандартизации, вероятно, не рассматривал подобные вещи подробно. Но когда C был стандартизирован ANSI и ISO, они должны были следовать определенным правилам стандартизации. Стандарты ISO не позволяют предвзято относиться к определенной технологии и тем самым давать определенной компании преимущество в конкурентной борьбе.

Поэтому им пришлось учитывать, что некоторые процессоры могут реализовывать неясные вещи, такие как дополнение, «знак и величина» или «некоторый способ, определяемый реализацией». Они должны были разрешить нули со знаком, биты заполнения и другие неясные целочисленные механизмы со знаком.

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

Разумным решением этой проблемы было бы не изобретать какие-то проверки безопасного диапазона, а скорее заявить, что все целые числа со знаком в языке C должны иметь формат дополнения до двух, конец истории. Тогда беззнаковый символ всегда будет от 0 до 127, а переполнение до -128, и все будет четко определено. Но искусственная стандартная бюрократия мешает стандарту стать разумным.

В стандарте C есть много подобных проблем. Выравнивание/заполнение, endianess и т. д.

Почему? Ну, потому что их не было в C, когда с этого начался C++, и потому что с тех пор никто не предлагал такие функции и не смог убедить создателей компиляторов и членов комитета в том, что они достаточно полезны, чтобы их предоставлять.

Обратите внимание, что компиляторы делают обеспечивают такие встроенные функции, так что дело не в том, что они против них.

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

Так что, наверное, просто не хватает интереса.