Претворять планы в жизнь как пишется

Язык Си — один из наиболее влиятельных языков программирования за всю историю. Он стал незаменимым инструментом разработки операционных систем, сместив с этого пьедестала языки ассемблера. Изучение Си обязательно для любого уважающего себя программиста. Этот язык любим за свою внешнюю простоту и ненавидим за беспощадность к ошибкам. Благодаря ему у нас есть ядро Linux и тысячи уязвимостей в нём же в придачу. Попробуем понять, что же такое этот противоречивый язык Си — благословение или проклятие?

История языка Си берёт свое начало в недрах американской компании Bell Labs и тесно связана с судьбой операционной системы UNIX. Ее создатели, Кен Томпсон и Деннис Ритчи, разрабатывали свой проект для компьютеров PDP-11, и первые два года их основным инструментом был язык ассемблера. Трудоёмкость написания машинного кода вынуждала искать ему замену, которой в конечном итоге и стал язык Си. С его помощью было полностью переписано ядро операционной системы и большая часть утилит. Язык Си позволял создавать эффективные низкоуровневые программы на PDP-11, практически не используя при этом язык ассемблера.

Со временем встал вопрос портирования UNIX на новые аппаратные платформы. Использование языка Си значительно упростило эту задачу. Ведь если бы в разработке применялся только язык ассемблера, то тогда операционную систему пришлось бы переписывать под каждую компьютерную архитектуру. С другой стороны, исходники UNIX все еще содержали немало кода, созданного специально для компьютера PDP-11. Да и сам язык Си далеко не всегда точно отражал особенности и детали той или иной аппаратной платформы. Последнее еще больше затрудняло процесс переноса и лишало язык одного из его главных достоинств — прозрачной и понятной генерации машинного кода. Чем больше компьютерных архитектур захватывал Си, тем менее очевидной становились его связь с низким уровнем.

В процессе миграции UNIX на новые аппаратные платформы обнаружилась ещё одна проблема. Портированные программы на языке Си исполнялись медленнее, нежели можно было от них ожидать. Чем сильнее отличалась целевая компьютерная архитектура от PDP-11, тем менее эффективным был получаемый код. Чтобы скомпенсировать этот недостаток, разработчики компиляторов всё чаще стали применять неявные оптимизации. И хотя такое решение и улучшало производительность самих программ, Си всё больше отдалялся от низкого уровня. Теперь приходилось не только понимать, как именно определялись конструкции языка для каждой из компьютерных архитектур, но также и то, как они оптимизировались. Разумеется, любой компилятор самостоятельно решал, как именно транслировать исходный код для каждой аппаратной платформы. В итоге написать на языке Си низкоуровневую программу, независящую от используемого компилятора, стало практически невозможно.

Необходимо было понять, как эффективно реализовать высокоуровневые конструкции языка Си, сохранив при этом его низкоуровневые свойства. Попыткой решить эту проблему стала публикация в 1989 году первого стандарта языка. Его принято называть «ANSI C» или «C89», и именно на него мы будем ссылаться в дальнейшем. Создатели стандарта решили окончательно разорвать связь Си с архитектурой PDP-11 и сделать язык полностью высокоуровневым. Была введена так называемая «абстрактная машина» — воображаемый исполнитель кода на языке Си (раздел 2.1.2.3, «Program execution»):

Семантические описания в этом Стандарте описывают поведение абстрактной машины, в которой вопросы оптимизации не имеют значения.

Это означает, что оптимизации компилятора не будут влиять на работу программы, пока её исходный текст согласуется со стандартом. Абстрактная машина должна была решить две проблемы одновременно. Во-первых, следование стандарту давало возможность создавать легко переносимые программы на языке Си. Во-вторых, абстрактная машина могла предоставить компиляторам свободу для оптимизаций. Вот только возникает вполне резонный вопрос — а чем тогда язык Си отличается от любого другого компилируемого языка высокого уровня? Ответ кроется в тексте стандарта. Чтобы всё-таки дать теоретическую возможность программистам писать низкоуровневые процедуры, а значит непереносимые, было введено ещё одно понятие — неопределённое поведение (undefined behavior, раздел 1.6, «DEFINITIONS OF TERMS»):

Неопределённое поведение — поведение при использовании непереносимой или ошибочной программной конструкции, ошибочных данных или объектов с неопределёнными значениями, для которых стандарт не накладывает никаких требований. Возможное неопределённое поведение варьируется от полного игнорирования ситуации с непредсказуемыми результатами, поведения во время трансляции или выполнении программы задокументированным образом, характерным для среды (с выдачей диагностического сообщения или без него), до прекращения трансляции или выполнения (с выдачей диагностического сообщения).

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

Возьмём следующий фрагмент кода на языке Си:

int x = 1;
x = x << sizeof(int) * 8;

Попробуем предположить, какой результат у нас получится. Допустим, мы скомпилировали этот код для процессоров архитектуры ARM. Инструкция битового сдвига в рамках этой аппаратной платформы определена так, что итоговым значением переменной «x» должен быть «0». С другой стороны, мы можем транслировать нашу программу в машинный код архитектуры x86. И уже там битовый сдвиг реализован таким образом, что значение «x» не изменится и останется равным «1». Мы могли бы сделать вывод, что результат работы данного фрагмента кода зависит от того, для какой аппаратной платформы мы его скомпилировали. Но на самом деле это не так.

В действительности данный фрагмент кода может быть обработан компилятором любым возможным и невозможным образом. Причина в следующем: согласно тексту стандарта языка Си битовый сдвиг на величину, большую или равную размеру выражения в битах, является неопределённым поведением. Получается, нет никакой гарантии, что этот кусок кода вообще будет работать. В действительности, даже в рамках одной архитектуры один и тот же компилятор может сгенерировать совершенно разные исполняемые файлы. Приведём примеры компиляции и запуска программы с печатью значения переменной «x». В обоих случаях мы используем компилятор gcc версии 10.2.1 для целевой архитектуры x86-64.

$ cat test.c
#include <stdio.h>

int main()
{
    int x = 1;
    x = x << sizeof(int) * 8;
    printf("%dn", x);
    return 0;
}
$ gcc test.c -o test
$ ./test
1
$ gcc -O test.c -o test
$ ./test
0

Флаг «-O» разрешает компилятору gcc использовать оптимизации исходного кода. То, какие именно механизмы оптимизации могут быть применены, а также какие флаги за них отвечают, зависит от конкретного компилятора. В общем случае невозможно узнать, каким образом будет обработано неопределённое поведение в программе при трансляции исходного кода. Поэтому единственный способ написания переносимых программ на языке Си — это полное избегание неопределённого поведения при разработке.

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

* (char *) 0;

Разумеется, никто в здравом уме не станет писать что-то подобное в своей программе. Однако совсем необязательно делать разыменование нулевого указателя явным образом, чтобы вызвать неопределённое поведение. В цикле статей «What Every C Programmer Should Know About Undefined Behavior» на сайте blog.llvm.org приводится фрагмент кода, подтверждающий это:

void contains_null_check(int *p)
{
    int dead = *p;
    if(p == 0)
        return;
    *p = 4;
}

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

void contains_null_check(int *p)
{
    if(p == 0)
        return;
    *p = 4;
}

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

void contains_null_check(int *p)
{
    int dead = *p;
    if(0)
        return;
    *p = 4;
}

Так как мы разыменовываем указатель до его проверки, то компилятор спокойно решает, что сам указатель никогда не будет нулевым. Благодаря этому сравнение «p == 0» заменяется на выражение, всегда возвращающее ложь. Затем компилятор запускает первый механизм оптимизации и убирает «мертвый» код:

void contains_null_check(int *p)
{
    *p = 4;
}

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

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

Оптимизации компилятора могут затрагивать также и функции стандартной библиотеки языка Си, в том числе, к примеру, memset. Она широко и печально известна за обилие ошибок, которые допускают программисты при её вызове. Заголовок функции выглядит следующим образом:

void *memset(void *ptr, int value, size_t num);

memset записывает «num» байтов со значением «value» по адресу «ptr». Несмотря на то, что параметр «value» имеет тип int, в действительности используется лишь его младший байт. Функция активно применяется для обнуления больших массивов данных, однако компилятор и сам частенько любит вставить её вызов туда, где это нужно и не очень. Так, любопытный случай обсуждался 15 апреля 2018 года на форуме osdev.org. Пользователь под ником ScropTheOSAdventurer создал тему, в которой рассказал о процессе разработки собственной учебной операционной системы. На свою беду он разрешил компилятору оптимизировать исходный код проекта, в результате чего последний перестал работать. В процессе отладки программист обнаружил ошибку в следующем фрагменте кода:

void *memset(void *ptr, int value, size_t num)
{
    unsigned char *ptr_byte = (unsigned char *) ptr;
    for(size_t i = 0; i < num; ptr_byte[i] = (unsigned char) value, i++);
    return ptr;
}

Для своей операционной системы разработчик решил использовать собственную реализацию функции memset. Но он не учёл, что в процессе трансляции компилятор gcc обнаружит в этом коде весьма заманчивую возможность для оптимизации. Фактически функция была в итоге преобразована к следующему виду:

void *memset(void *ptr, int value, size_t num)
{
    return memset(ptr, value, num);
}

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

Приведем еще один пример с функцией memset. Компилятор способен не только создавать её вызовы на пустом месте, но и выкидывать их из исходного кода по собственному желанию. Так, в криптографических программах зачастую бывает полезно стирать все данные из памяти после того, как они перестают быть нужными. Обычно такое поведение является избыточным, однако представим себе следующую ситуацию. Ваша программа работает с базой данных пользователей, хранящей их имена и пароли, и вы описали примерно такую функцию:

int check_password(const char *pwd)
{
    char real_pwd[32];
    get_password(real_pwd);
    return !strcmp(pwd, real_pwd);
}

Есть лишь одна проблема — после вызова check_password в стеке останется строка с настоящим паролем пользователя. Если в вашей программе есть хотя бы одна уязвимость, позволяющая читать данные из памяти, то существует реальная вероятность украсть пароль из стека. Примером подобной уязвимости стал печально известный баг «Heartbleed». Чтобы снизить возможные риски, проще всего очистить содержащий пароль фрагмент стека:

int check_password(const char *pwd)
{
    int result;
    char real_pwd[32];
    get_password(real_pwd);
    result = !strcmp(pwd, real_pwd);
    memset(real_pwd, 0, sizeof(real_pwd));
    return result;
}

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

Одной из наиболее коварных разновидностей неопределённого поведения является strict aliasing. Термин может быть переведён как «строгое наложение», однако традиционного названия на русском языке у него не существует. По этой причине мы будем использовать оригинальный английский термин. Текст стандарта дает такое описание для strict aliasing (раздел 3.3, «EXPRESSIONS»):

Значение объекта должно быть доступно только с помощью lvalue-выражения одного из следующих типов:

— объявленный тип объекта,

— квалифицированная версия объявленного типа объекта,

— знаковый или беззнаковый тип, соответствующий объявленному типу объекта,

— знаковый или беззнаковый тип, соответствующий квалифицированной версии объявленного типа объекта,

— тип массива, структуры или объединения, который включает в себя один из вышеупомянутых типов среди своих членов (включая, рекурсивно, член внутренней структуры, массива или объединения),

— символьный тип.

Проще всего strict aliasing проиллюстрировать на конкретном примере:

int x = 42;
float *p = &x;
*p = 13;

Чтобы вызвать неопределенное поведение, достаточно обратиться к какой-либо переменной по типу, несовместимому с объявленным. Это ограничение можно обойти, применив символьный тип (char), на который не распространяются правила strict aliasing:

int x = 42;
char *p = &x;
*p = 13;

Вот только расчленение переменной на символы может оказаться трудоемкой задачей. Придется учитывать размер данных, а также используемый порядок байтов. Избежать неопределённого поведения можно также с помощью объединений (union):

union u { int a; short b };
union u x;
x.a = 42;
x.b = 13;

Впрочем и этот метод не лишён недостатков — объединение должно содержать члены со всеми возможными типами, которые будут использованы программой. Все это серьёзно осложняет применение «type punning» или так называемого каламбура типизации — намеренного нарушения системы типов. Эта техника необходима для более гибкого низкоуровневого управления памятью машины.

Чтобы проиллюстрировать пользу каламбура типизации, разберем небольшой пример. Допустим, вы прочитали содержимое файла с изображением в память программы. И теперь вам требуется написать функцию, которая возвращает цвет пикселя по указанным координатам. Для простоты будем считать, что размер типа int совпадает с размером пикселя, как и порядок байтов у обоих:

int get_pixel(const char *buf, int width, int x, int y)
{
    buf += get_header_size(buf);
    return ((const int *) buf)[y * width + x];
}

При вызове функции ей передается адрес области данных с содержимым файла, включая его заголовок, ширину изображения, а также координаты пикселя, цвет которого следует вернуть. Вместо типа int мы могли бы выбрать любой другой с известным нам размером. Но все это неважно, потому что функция get_pixel абсолютно неверна с точки зрения стандарта, так как нарушает правила strict aliasing. Чтобы использовать каламбур типизации, придется переписать весь код, связанный с используемым буфером, в том числе и тот, который ответственен за чтение файла.

Существует огромное количество примеров программ, не удовлетворяющих правилам strict aliasing. В их число входит знаменитая функция вычисления быстрого обратного квадратного корня из игры Quake 3:

float FastInvSqrt(float x)
{
    float xhalf = 0.5f * x;
    int i = *(int *) &x;
    i = 0x5f3759df - (i >> 1); /* What the fuck? */ 
    x = *(float *) &i;
    x = x * (1.5f - (xhalf * x * x));
    return x;
}

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

Остается один вопрос — зачем вообще нужен этот strict aliasing? Все дело в том, что он позволяет создателям компиляторов применять крайне агрессивные оптимизации исходного кода. Правила strict aliasing распространяются на обращения к любой памяти, в том числе и динамической. Так комитет стандартизации отметил, что следующий фрагмент кода (источник):

void f(int *x, double *y)
{
    *x = 0;
    *y = 3.14;
    *x = *x + 2;
}

может быть преобразован таким образом:

void f(int *x, double *y)
{
    *x = 0;
    *y = 3.14;
    *x = 2;
}

Согласно правилам strict aliasing указатель y не может содержать адрес того же участка памяти, что и указатель x. Именно этот факт и позволяет заменить выражение «*x = *x + 2» на «*x = 2». Активное использование компиляторами подобных оптимизаций сломало огромное количество старого кода. Так, в письме от 12 июля 1998 года один из разработчиков компилятора gcc Jeff Law, отвечая на вопросы по strict aliasing и связанными с ним ошибками, пишет (источник):

> Существует очень много кода, который нарушает правила strict aliasing. Одним из таких примеров является «переносимая» универсальная функция контрольной суммы IP, которая содержится в исходных кодах BSD для работы с сетями.

ИМХО, такого кода становится все меньше и меньше — современные компиляторы уже какое-то время используют strict aliasing в анализе, в результате чего люди были вынуждены исправлять свой код. Безусловно, это не относится к Linux и некоторым другим свободным проектам, так как они используют только gcc.

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

Укажите им на стандарт языка Си

Правила strict aliasing для компилятора gcc можно разрешить, используя флаг «-fstrict-aliasing», и запретить флагом «-fno-strict-aliasing». Последний рекомендуется применять, если вы не уверены, нарушаете ли вы текст стандарта — скорее всего, нарушаете. Говоря об упомянутом в письме ядре Linux, его автор Линус Торвальдс также дал свою оценку strict aliasing в частности и работе комитета в целом. Так, критикуя желание одного из разработчиков операционной системы лишний раз перестраховаться от нарушения стандарта, Линус написал такое письмо (источник):

Честно говоря, все это кажется мне сомнительным.

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

Дело в том, что использование объединений для реализации каламбура типизации — это обычный и СТАНДАРТНЫЙ для этого способ. В действительности он является документированным для gcc, и используется в том случае, если вы, будучи не слишком умным (оригинал: «f*cking moron»), применили «-fstrict aliasing», и теперь вам необходимо избавиться от всего того ущерба, который навязывает этот мусорный стандарт.

Энди, что послужило причиной для всего этого идиотизма? И не надо говорить мне, что текст стандарта «недостаточно ясный». Текст стандарта, совершенно ясно, является дерьмовой чушью (см. выше о правилах strict aliasing), и в таких случаях его нужно игнорировать. Для этого необходимо использовать средства компилятора, чтобы избежать ущерба. Аналогично нужно поступать и в ситуациях, где нет полной ясности.

Это то, почему мы используем «-fwrapv», «-fno-strict-aliasing» и другие флаги.

Я уже говорил об этом раньше и повторю еще раз: когда текст стандарта противоречит реальности — он является обычным куском туалетной бумаги. Он не имеет абсолютно никакой важности. В действительности, вместо него я лучше возьму рулон настоящей туалетной бумаги — так хотя бы я не испачкаю свою задницу чернилами (оригинал: «won’t have splinters and ink up my arse»).

Видимо, Линус Торвальдс плохо изучил язык Си — настоящему программисту на Си такое в голову бы не пришло.

Впрочем, одним лишь strict aliasing стандарт не полон. Чтобы вызвать неопределённое поведение, необязательно даже разыменовывать указатель:

void f(int *p, int *q)
{
    free(p);
    if(p == q) /* Undefined behaviour! */
        do_something();
}

Использование значения указателя после того, как память по нему была освобождена, запрещено текстом стандарта (раздел 4.10.3, «Memory managment functions»):

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

Программисту важно понимать, что указатели в Си не являются низкоуровневыми. Стандарт постарался полностью искоренить какую-либо связь языка с реальным миром. Даже сравнение указателей, ссылающихся на разные объекты, объявлено неопределённым поведением (раздел 3.3.8, «Relational operators»):

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

Вот небольшой фрагмент кода, демонстрирующий некорректное с точки зрения стандарта сравнение:

int *p = malloc(64 * sizeof(int));
int *q = malloc(64 * sizeof(int));
if(p < q) /* Undefined behaviour! */
    do_something();

Однако наиболее интересным примером здесь будет служить исходный код следующей программы:

#include <stdio.h>

int main()
{
    int x;
    int y;
    int *p = &x + 1;
    int *q = &y;
    printf("%p %p %dn", (void *) p, (void *) q, p == q);
    return 0;
}

Если транслировать приведенный выше текст компилятором gcc, передав ему флаг «-O», то полученный исполняемый файл при запуске выдаст примерно следующую строку:

0x1badc0de 0x1badc0de 0

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

Большая часть примеров, связанных с работой указателей, была взята с сайта kristerw.blogspot.com. На нём вы сможете найти больше информации о текстах стандарта языка Си, а также загадочных оптимизациях компиляторов.

Может показаться, что в случае выключенных оптимизаций все вышеописанные проблемы обойдут вас стороной. Просто не передавайте компилятору флаг «-O», и вы получите тот результат, на который рассчитываете. Но на самом деле это не так. В январе 2007-ого года на сайте gcc.gnu.org пользователь под ником felix-gcc выложил исходный код следующей программы:

#include <assert.h>

int foo(int a) {
  assert(a + 100 > a);
  printf("%d %dn",a + 100, a);
  return a;
}

int main() {
  foo(100);
  foo(0x7fffffff);
}

Функция foo проверяет на переполнение сумму поданного знакового числа и константы «100». Как известно, на подавляющем большинстве компьютерных архитектур отрицательные числа задаются в виде дополнительного кода. В случае переполнения такое число меняет знак на противоположный, благодаря чему проверка «a + 100 > a» возвращает ложь. В теле функции main felix-gcc дважды вызывает foo. Сначала он подает на вход число, которое не приведёт к переполнению. Затем, исходя из того, что размер типа данных int равен четырем байтам, felix-gcc вызывает foo с наибольшим положительным числом данного типа. Логично предположить, что в таком случае сравнение вернёт ложь, и assert прервёт работу программы. Однако вот какой вывод получил felix-gcc после запуска исполняемого файла:

200 100
-2147483549 2147483647

Фактически gcc решил удалить проверку на переполнение, и это при том, что никаких флагов компилятору передано не было. И что еще интереснее, ранние версии gcc при тех же условиях не убирали проверку, в результате чего получаемая программа вела себя иначе. На резонную просьбу felix-gcc исправить неожиданный баг компилятора ответил пользователь под ником Andrew Pinski. Будучи разработчиком gcc, Andrew Pinski заметил, что данное поведение не является ошибочным. Более того, он сам оказался автором изменения в коде компилятора, которое и создало столь странный результат. Далее приводится фрагмент диалога felix-gcc и Andrew Pinski. Комментарии излишни:

Andrew Pinski
Переполнение знакового числа — это неопределённое поведение в тексте стандарта языка Си, используйте беззнаковый тип или флаг «-fwrapv».

felix-gcc
Вы должно быть шутите?
Различные проблемы безопасности вызваны переполнениями чисел, и вы просто так говорите мне, что в gcc 4.1 я больше не могу тестировать их для знаковых типов? Вы явно чего-то не понимаете. ДОЛЖЕН быть способ обойти эту проблему. Существующее программное обеспечение использует знаковые числа, и я не могу просто поменять тип на беззнаковый — мне все равно нужно проверить переполнение! Не похоже, что я мог бы использовать какой-нибудь обходной путь для этого. Что вы хотите от меня — чтобы я привел тип к беззнаковому, сдвинул вправо на один, затем сложил или что вообще?!
ПОЖАЛУЙСТА, ОТМЕНИТЕ ЭТО ИЗМЕНЕНИЕ. Оно создаст СЕРЬЁЗНЫЕ ПРОБЛЕМЫ БЕЗОПАСНОСТИ во ВСЕВОЗМОЖНЫХ ПРОГРАММАХ. Меня не волнует, что ваши стандартизаторы говорят о том, что gcc исправен. ВСЕ ЭТО ПРИВЕДЁТ К ТОМУ, ЧТО ЛЮДЕЙ ВЗЛОМАЮТ. Я обнаружил эту проблему, так как одна из проверок безопасности, которая предотвращает взлом, провалилась.
ЭТО НЕ ШУТКА. ИСПРАВЬТЕ ЭТО! СЕЙЧАС ЖЕ!

Andrew Pinski
Я не шучу, стандарт языка Си прямо говорит, что переполнение знакового числа — это неопределённое поведение.

felix-gcc
Так, послушайте, Эндрю, вы что, действительно думаете, что эта проблема исчезнет, если вы продолжите закрывать баги достаточно быстро? Проверка, которую я написал, покрывала все возможные ситуации. Не требуется даже уточнения того, что за тип используется — указатель, беззнаковое или знаковое число. Ну, указатели вы тоже сломали, но ваши изменения были исправлены. Парень, который сделал это тогда, должен появиться здесь, нам нужен кто-то с трезвой головой и видением ситуации как у него.
Давайте посмотрим правде в глаза — вы облажались по полной (оригинал: «fucked up this royally»), и теперь вы пытаетесь прикрыть все ошибки как можно скорее, чтобы никто не заметил, сколько ущерба вы нанесли. Вы, сэр, непрофессиональны и позорите команду разработчиков gcc. Эта ошибка останется открытой до тех пор, пока вы не вернёте все обратно или не сделаете упомянутый вами флаг по умолчанию. Пока вы будете ломать программы, чьи авторы по глупости включили оптимизации, мне всё равно. Но я не позволю вам делать моё окружение менее безопасным только потому, что ваш непрофессионализм не позволяет вам разобраться с оптимизациями после того, как было показано, что они наносят больше вреда, чем пользы. Сколько еще доказательств вам необходимо предоставить? Боже мой, да autoconf считает, что ваши «оптимизации» нужно отключать повсеместно. Вы вообще замечаете взрывы вокруг самих себя?

Andrew Pinski

http://c-faq.com/misc/sd26.html

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

felix-gcc
МОЙ КОД НЕ СЛОМАН.
Попытки обесценить проблему или оскорбить меня ничего не решат.

Andrew Pinski
Вы написали ошибку, поэтому я и решил, что ваш код сломан.

felix-gcc
Итак, скажите мне, какая часть моей аргументации вам непонятна? Я мог бы использовать слова попроще, чтобы вы смогли меня понять на этот раз.
Ребята, ваша задача — это не просто реализовать стандарт Си. Вы также обязаны не нарушать работу программ, которые зависят от вас. А от вас зависит МНОГО программ. Когда вы нарушили точность вычислений с плавающей точкой, то вы сделали это доступным с помощью флага (-ffast-math). Когда вы добавили strict aliasing, вы так же сделали эту функцию доступной через флаг (-fstrict-aliasing). Если я правильно помню, вы тогда тоже цитировали текст стандарта, пока люди с более адекватным пониманием мира вас не остановили. И я собираюсь оставить эту ошибку открытой до тех пор, пока не повторится та же история.

Andrew Pinski
Я думаю, нам не следовало делать это необязательным, но меня не было в тот момент, когда было принято это решение. Также помните, что у нас был релиз, когда strict aliasing был включен, но затем нам пришлось его отключить по умолчанию. За это время люди исправляли свои программы, пока оптимизация была активна. И мы уже сделали оптимизацию знакового переполнения опциональной с помощью «-fwrapv». Я не понимаю, к чему вы приводите свои аргументы.

felix-gcc
Вы не можете просто так потенциально сломать кучу свободного ПО лишь потому, что изменили свое мнение по поводу того, какую свободу вам дает стандарт.
Повзрослейте или уйдите, позволив более ответственным людям заниматься вашими делами.

Andrew Pinski
Подождите, но эта оптимизация была еще с 1994-ого года, и если какой-либо код, начиная с этого момента, использовал знаковое переполнение, то авторы этих программ сами напросились.

felix-gcc
Знаете ли вы, что ракета Ариан-5 взорвалась (и могла убить людей!) из-за ошибки переполнения? Что если люди погибнут из-за того, что вы решили, что стандарт позволяет вам выкидывать проверки безопасности, написанные людьми?

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

felix-gcc
Еще раз: НЕ ИМЕЕТ ЗНАЧЕНИЯ ТО, ЧТО ГОВОРИТ СТАНДАРТ. Вы сломали программы, и люди пострадали от этого. Теперь верните все обратно. Меньшее, что вы можете, это сделать «-fwrapv» по умолчанию. Вам все еще придётся заставить его работать правильно (я слышал, что он неверно работает в определенных ситуациях), но это уже другая история.

Andrew Pinski
Он будет по умолчанию в тех языках, где определено именно такое поведение. Я дал вам способ написания проверок переполнения, и если вам не нравится то, что говорит стандарт языка Си, то это не моя вина.
Запомните: компилятор gcc также является оптимизирующим компилятором, и если вам нужны оптимизации, то вы должны следовать правилам того языка, на котором вы пишете, вместо создания неверных программ, что и происходит с Си и Си++ в целом.

felix-gcc
В ранних версиях компилятора такое поведение происходило только в случае включённых оптимизаций. Если немножко присмотреться, то окажется, что все ваши аргументы ничего не стоят.
Потому как gcc 4.1 выкидывает этот код уже без включённых оптимизаций. Вот и все ваши аргументы.
Пожалуйста, сделайте «-fwrapv» по умолчанию, и я заткнусь.

Andrew Pinski
Попробуйте проверить время исполнения программы с «-fwrapv» и без него. Вы увидите, что без него код работает быстрее.

Пытаясь уйти в обсуждение оптимизаций компилятора, Andrew Pinski решил тем самым оправдать свою позицию. В процессе он, однако, упомянул куда более «интересную» аргументацию:

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

А в самом конце обсуждения Andew Pinski заявил следующее:

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

В заключение хочется привести еще одну цитату Линуса Торвальдса:

Разработчики gcc больше заинтересованы в попытках выяснить, что еще им позволяет делать стандарт, чем в том, как заставить вещи действительно работать.

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

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

Мы позволим компилятору лгать вам. Мы будем лгать вашему коду. И когда дела пойдут плохо — ошибка, «обосратушки», утечка памяти — мы торжественно покачаем головами.

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

Соавтор статьи: @aversey

Изначальная публикация: cmustdie.com