Почему беззнаковые целые числа подвержены ошибкам?

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

for(size_t i = foo.size(); i >= 0; --i)
    ...

Обратите внимание, что по определению i >= 0 всегда верно. (Во-первых, это вызвано тем, что если i подписано, компилятор предупредит о возможном переполнении с size_t из size()).

Упоминаются и другие причины: Опасность — здесь используются неподписанные типы!, самым сильным из них, на мой взгляд, является неявное преобразование типов между подписанным и беззнаковым.

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

void fun (const std::vector<int> &vec) {
    for (std::size_t i = 0; i < vec.size() - 1; ++i)
        do_something(vec[i]);
}

Выглядит хорошо, не так ли? Он даже компилируется чисто с очень высоким уровнем предупреждений! (Live) Итак, вы помещаете это в свой код, все тесты проходят гладко, и вы забываете об этом.

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

Но в вашей реализации с целым числом без знака вы выполняете перенос, и условие цикла становится i < SIZE_T_MAX. Катастрофа, УБ и скорее всего крах!

Я хочу знать, как они приводят к ошибкам безопасности?

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

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

#include <iostream>

int main() {
    unsigned n = 42;
    int i = -42;
    if (i < n) {
        std::cout << "All is well\n";
    } else {
        std::cout << "ARITHMETIC IS BROKEN!\n";
    }
}

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

Хотя это можно рассматривать только как вариант существующих ответов: ссылаясь на "Подписанные и неподписанные типы в интерфейсах ," C++ Report, September 1995 Скотта Мейерса, особенно важно избегать беззнаковых типов в интерфейсах.

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

Приведенный там пример:

template <class T>
  class Array {
  public:
      Array(unsigned int size);
  ...

и возможный экземпляр этого класса

int f(); // f and g are functions that return
int g(); // ints; what they do is unimportant
Array<double> a(f()-g()); // array size is f()-g()

Разница значений, возвращаемых f() и g(), может быть отрицательной по целому ряду причин. Конструктор класса Array получит эту разницу как значение, которое неявно преобразуется в unsigned. Таким образом, как разработчик класса Array, вы не можете отличить ошибочно переданное значение -1 от выделения очень большого массива.

Большая проблема с unsigned int заключается в том, что если вы вычтете 1 из unsigned int 0, результат не будет отрицательным числом, результат не меньше, чем число, с которого вы начали, но результатом будет максимально возможное значение unsigned int. .

unsigned int x = 0;
unsigned int y = x - 1;

if (y > x) printf ("What a surprise! \n");

И это то, что делает unsigned int подверженным ошибкам. Конечно, unsigned int работает именно так, как задумано. Это абсолютно безопасно, если вы знаете, что делаете, и не делаете ошибок. Но большинство людей совершают ошибки.

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

Проблема с беззнаковыми целочисленными типами заключается в том, что в зависимости от их размера они могут представлять одну из двух разных вещей:

1. Типы без знака меньше int (например, uint8) содержат числа в диапазоне 0..2ⁿ-1, и вычисления с ними будут вестись в соответствии с правилами целочисленной арифметики при условии, что они не превышают диапазон тип int. Согласно существующим правилам, если такое вычисление выходит за пределы диапазона int, компилятору разрешается делать с кодом все, что ему заблагорассудится, вплоть до отрицания законов времени и причинно-следственных связей (некоторые компиляторы делают именно это!) , и даже если результат вычисления будет присвоен обратно беззнаковому типу, меньшему, чем int.
2. Типы без знака unsigned int и более крупные содержат элементы абстрактного обертывающего алгебраического кольца целых чисел, конгруэнтных по модулю 2ⁿ; это фактически означает, что если вычисление выходит за пределы диапазона 0..2ⁿ-1, система добавит или вычтет любое число, кратное 2ⁿ, которое потребуется, чтобы вернуть значение в диапазон.

Следовательно, при заданном uint32_t x=1, y=2; выражение x-y может иметь одно из двух значений в зависимости от того, превышает ли int 32 бита.

1. Если int больше 32 бит, выражение вычтет число 2 из числа 1, что даст число -1. Обратите внимание, что хотя переменная типа uint32_t не может содержать значение -1 независимо от размера int, и сохранение -1 приведет к тому, что такая переменная будет содержать 0xFFFFFFFF, но до тех пор, пока значение не будет приведено к беззнаковому типу, оно будет вести себя как подписанная величина -1.
2. Если int составляет 32 бита или меньше, выражение даст значение uint32_t, которое при добавлении к значению uint32_t 2 даст значение uint32_t 1 (т. е. значение uint32_t 0xFFFFFFFF).

ИМХО, эту проблему можно было бы решить чисто, если бы C и C++ определяли новые беззнаковые типы [например, unum32_t и uwrap32_t], так что unum32_t всегда будет вести себя как число, независимо от размера int (возможно, потребуется правая операция вычитания или унарного минуса для повышения до следующего большего знакового типа, если int равно 32 битам или меньше), в то время как wrap32_t всегда ведет себя как член алгебраического кольца (блокируя продвижение, даже если int больше 32 бит). Однако в отсутствие таких типов часто невозможно написать код, который одновременно переносим и чист, поскольку переносимый код часто требует приведения типов повсюду.

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

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

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

В качестве другого примера рассмотрим умножение двух целых чисел без знака одинакового размера.

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

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