Подводные камни С++. Решаем загадки неопределённого поведения, ч. 1

Авторы стандартов используют предельно лаконичные и строгие формулировки, иноязычные читатели стандартов нагружают прочтённое адекватными их знаниям чужого языка собственными смыслами — и в результате мы получаем настоящие “перлы” типа “Никто не знает, как будет вести себя код, содержащий UB.”

Текст вроде и осмысленный, и корректный, и кому-то на что-то откроет глаза, но в его основе лежит семантическое заблуждение, и потому весь текст получается вовсе не о том, о чём заявляется заголовком, а местами и вовсе заставляет задуматься — а не ставит ли автор телегу впереди лошади? Не попутаны ли причинно-следственные связи?

О каком семантическом заблуждении я? Излагать буду максимально подробно. Автор (масса авторов и комментаторов по всему интернету, к сожалению) в обсуждаемых терминах Стандарта “undefinded behaviour”, ”unspecified behaviour”, “implementation-defined behaviour” привязывает первое слово к последнему как характеристику последнего. В результате мы получаем чушь в форме “код, содержащий UB”. Извините, но B (поведение) скомпилированного кода очень даже определено — архитектурой целевой платформы и средой исполнения.Код не может содержать какого-то там неопределённого поведения. Или неуточнённого. Или реализацией-определямого. Он всегда будет исполняться так, как определено, повторюсь, архитектурой целевой платформы и средой исполнения.

Пример:

#include <inttypes.h>
#include <stdio.h>

static uint8_t a[3] = { 1, 0, 1 };

int main(void)
{
        printf("%hd/%hd\n", *(uint16_t *)a, *(uint16_t *)(a + 1));

        return 0;
}

Эта смешная программка (“содержащая UB”, выражаясь в стиле автора) на AMD64 всегда, будучи хоть миллиард раз запущена, выведет 1/256. Очень даже определённое поведение.

Эта же смешная программка на ARM точно так же всегда выведет — ахтунг! начинается интересное — либо 1/256, либо 256/1, и зависит это от среды исполнения (для тех, кто не знает — порядок байтов в многобайтовых словах, так называемый endian, на ARM настраивается при старте, и может быть как little, так и big), Но в одной и той же среде результат при миллиардах запусков будет один, то есть поведение вполне себе определённое.

И эта же смешная программка на PDP-11/VAX всегда, сколько ни запускай, фолтнется с bus error. И это тоже вполне определено, нельзя там выдёргивать слово по нечётному адресу.

То есть, поведение программки всегда детерминировано, полностью определено. Но позвольте, она же “содержит UB”, как же так?

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

Попробуем теперь переосмыслить и выразить простым русским языком значения этих терминов:

unspecified behaviour — Стандарт определяет, что параметры функции конечно же будут вычислены, и это точно произойдёт до вызова функции, но Стандарт не уточняет порядок вычисления этих параметров в случае, когда их более одного.

implementation-defined behaviour — Стандарт не определяет, что будет со старшим битом знакового целочисленного типа при сдвиге вправо, но предписывает авторам реализации чётко определить в документации на их компилятор, что при этом будет происходить в этой конкретной реализации.

undefined behaviour — Стандарт не определяет, каким будет результат использования той или иной языковой конструкции в исполняемом коде на целевой платформе в целевой среде исполнения.

Чувствуете же разницу, друзья-коллеги? Не “Поведение неопределённое”, а “Стандарт никоим образом не определяет, каким должно быть поведение” при целочисленном делении на 0 — на PDP-11/VAX всегда и определённо трапнется, на MIPS молча и так же всегда и c чётко определённым результатом поедет дальше.

Ничего феноменального в UB нет, надо лишь вспомнить чуть-чуть историю языка C. Его не зря всегда сравнивали с высокоуровневым ассемблером — это язык очень низкого уровня, почти абстрактный ассемблер и есть. Множество архитектур, на которые он был в то или иное время перенесён, имеют существенные различия. И эти различия не особо напрягали как отцов, так и многочисленных “портировщиков” UNIX (напоминаю — C родился для создания переносимой UNIX) на другие платформы, принципиальные отличия в архитектуре решались условной компиляцией и чистым ассемблером в совсем уж железо-зависимых частях.

Но потом появился Стандарт. И члены рабочей группы прекрасно понимали, что решение проблем разности архитектур при таком многообразии архитектур — mission impossible. Для упрощения проблем реализаций сначала определили кучу implemetation-defined behaviour, а потом, абстрагируясь всё выше, и undefined behaviour.

А потом “в тусовку” пришли дети Фортрана и Бейсика, решившие, что они тоже хотят писать на C всё те же свои математические, физические, экономические и прочие очень далёкие от “железа” программы. Им многого не хватало из привычных им сред, и они стали прессовать Комитет. И Комитет повёлся. В язык стали вводить конструкции, которые стали превращать очень низкоуровневый C во всё более высокоуровневый язык (взять хотя бы те же VLA). И ситуация дошла “до ручки”. Одно из самых свежих нововведений — сравнение указателей, не относящихся к одной и той же области storage— UB. У кучи разработчиков системного (очень низкого) уровня подорвались пердаки. Мегасрачи на reddit. Но всё же понятно при всей своей непонятности: тому, кто не знает, чем стэнфордская архитектура отличается от гарвардской архитектуры, тяжело понять, почему нельзя сравнивать указатели на код с указателями на данные. Но как быть в системах, где нет защиты памяти, и можно сгенерить код в области данных, и передать ему управление (привет вирусописателям)? А как быть на гарвардской архитектуре, где код лежит в 16-разрядной памяти, а данные — в 32-разрядной?

Комитет пошёл на поводу у людей, которые о low-level программировании — ни ухом, ни рылом, какими бы доками они ни было в квантовой физике и макроэкономике. Комитет смирился с идеей превратить низкоуровневый C в высокоуровневый C-хрен_знает_что. Язык, на котором можно было (и неоднократно реализовано) делать операционные системы, превращается в сверхвысокоуровневое, не имеющее никакого отображения на железо, нечто, на котором можно писать очередное 1С, но ОС или хотя бы драйвер — нет, ребята, пишите на ассемблере.

А потом C++ посредством механизма наследования (какая издёвка над столпами ООП) получил всё это дерьмо на свой обеденный стол. Держитесь, ребята. Или, осознавая существенные отличия архитектур, переносимо операционки писать, или разргребать, подобно дерьму, существенные отличия архитектур в угоду Васе, который не может понять, почему нельзя просто поделить икс на игрек...

Некорректно написанная программа (Ill-formed program) — программа, которая нарушает либо синтаксические, либо семантические правила (либо и те, и другие). Она не должна компилироваться.

Также бывает "Ill-formed, no diagnostic required" — программа некорректна, но имеет полное право компилироваться без предупреждений. Что произойдёт при попытке запустить — не определено. Может выдать верный ответ, может выдать неверный ответ, может не запуститься, может вести себя по-разному в зависимости от настроек ОС. Типичный пример — static initialization order fiasco.

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

This diagnostics is produced. I'd like to point out that clang behaves similarly (albeit this is not really relevant when we talk about the correctness).

UB - стандарт говорит компилятору делай как хочешь.

Тем больше UB, тем больше свободы разработчикам компиляторов.

Тем больше свободы, тем больше кто в лес, кто по дрова.

В итоге ты смотришь на код и НЕ ПОНИМАЕШЬ что же в итоге выполнится.

В общем, стандарт плохой и из-за этого язык стал "плохим".

И комитет ещё не спит, сыпет новыми версиями стандартов с новыми UB.

Можно всю жизнь учить c++ и все равно не знать что же происходит. Особенно в чужом коде :'(

Но если первой отработает RNCE, то код станет таким (оптимизатор видит, что ptr проверяется на NULL уже после разыменования, соответственно, проверка бессмысленна):

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

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