Hardening
#опытным

Раз уж в прошлом посте заикнулись про hardening, давайте разберем его чуть подробнее.

Неопределенное поведение (UB) в C++ - самая ужасная категория ошибок. UB может бесшумно повреждать память, вызывать сбои в местах очень отдаленных от фактической ошибки, или, что хуже всего, просто работать на вашей машине долгое время без спецэффектов. Значительная доля UB в реальных кодовых базах происходит не от экзотических языковых функций, а от базового неправильного использования стандартной библиотеки: доступа к вектору за пределами границ, вызова front() на пустом контейнере или вызова метода на пустом std::optional.

C++26 частично решает эту проблему напрямую с помощью харденинга стандартной библиотеки

Что это за зверь?

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

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

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

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

Примеры:

std::vector<int> v = {1, 2, 3};

// нарушение контракта: 5 >= 3

int x = v[5];



v.pop_back();

v.pop_back();

v.pop_back();

// нарушение контракта: нельзя убрать элемент из пустого вектора

v.pop_back();



std::string_view sv("hello");

// нарушение контракта: 10 >= 5

char c = sv[10];

// нарушение контракта: 10 > 5

sv.remove_prefix(10);



std::optional<int> opt;

// нарушение контракта: нет реального объекта

int x = *opt;



int data[10];

// нарушение контракта: разное число элементов 

// в шаблонном параметре и в аргументе конструктора

std::span<int, 5> sp(data, 3);

// нарушение контракта: 10 > size()

sp.first<10>();

Сильнейший аргумент в пользу этой включения харденинга — производственный опыт Google, на который ссылается пропоузал: применение харденизированного libc++ в «сотнях миллионов строк C++» выявило более 1000 ошибок, включая критически важные для безопасности. Средние накладные расходы на производительность оказались удивительно низкими — 0,30%(одна треть процента). Эти накладные расходы остались такими низкими благодаря способности компилятора устранять избыточные проверки во время оптимизации.

Влияние вышло за рамки безопасности: команды наблюдали 30%‑е снижение базового уровня сегментационных ошибок (segfault) в продуктивной среде, что указывает на повышение корректности кода в целом.

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

Be safe. Stay cool.

#cpp26 #compiler