C++ C++ · 30 вопросов · ~85 мин · ⏱ Таймер 25:00 · Сложный ·

Неопределённое поведение C++

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

Отвечено: 0 из 30

⏱ --:--

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

Вопрос 1 из 30

Каково поведение функции?

int& bad(){
    int x = 42;
    return x;
}

Висячая ссылка; использование даёт UB Компилятор обязан вернуть 0 Возвращаемое значение копируется из локальной переменной до завершения её времени жизни, поэтому ссылка безопасна Ссылка продлевает жизнь x Код всегда не компилируется

Вопрос 2 из 30

Почему чтение `*p` после `delete p` не становится безопасным, даже если память “ещё не перезаписана”?

int* p = new int(42);
delete p;

if (memory_still_looks_intact())
    std::cout << *p; // время жизни int уже закончилось

Жизнь объекта завершена вызовом delete, и прежний адрес больше не обозначает живой int Чтение разрешено до ближайшего new; запрещена только запись по освобождённому адресу Delete ставит служебный флаг, но объект остаётся жив до следующего выделения того же размера Use-after-free определён, пока программа не меняет байты освобождённого блока Совпадение числового адреса гарантирует продолжение времени жизни прежнего объекта

Вопрос 3 из 30

Безопасен ли `std::string_view` на результат `s.substr(...)`, если substr возвращает временную string?

std::string source = "abcdef";
std::string_view tail = source.substr(2);

// substr создаёт временную std::string, уничтоженную в конце инструкции.
std::cout << tail;

Да: string_view забирает владение временной подстрокой и освобождает её позже Безопасность зависит только от длины подстроки и small-string optimization Нет: временный std::string из substr уничтожается в конце полного выражения Код не компилируется, потому что string_view нельзя построить из std::string Да: substr для std::string автоматически возвращает string_view при таком присваивании

Вопрос 4 из 30

Можно ли читать неактивный член union как другой тип произвольно?

union Value {
    std::uint32_t integer;
    float real;
};
Value v{.integer = 0x3f800000};
float x = v.real; // чтение неактивного члена

Нет: доступ к неактивному члену ограничен специальными правилами и не является общим способом type punning Да, если sizeof обоих типов совпадает, независимо от времени жизни активного члена Да: union предоставляет переносимый bit-cast между любыми членами Union автоматически хранит индекс активной альтернативы и проверяет его как variant Запрещена только запись в неактивный член, а чтение всегда определено

Вопрос 5 из 30

Что нужно после получения сырого выровненного хранения для нетривиального T?

alignas(Packet) std::byte storage[sizeof(Packet)];
Packet* packet = std::construct_at(
    reinterpret_cast<Packet*>(storage), header, payload
);
use(*packet);
std::destroy_at(packet);

Обнулить хранилище; нулевое представление автоматически вызывает конструктор по умолчанию Получить T* через приведение и читать поля: выровненных байтов достаточно для начала жизни нетривиального T Начать время жизни объекта вызовом `std::construct_at` или placement new Пометить указатель volatile, чтобы компилятор считал объект сконструированным Освободить подготовленный буфер и обязательно выделить новый через `new T`

Вопрос 6 из 30

Почему чтение float через `reinterpret_cast<int*>(&f)` опасно?

float value = 1.0f;
int bits = *reinterpret_cast<int*>(&value);

std::cout << std::hex << bits;
// Доступ через int* нарушает правила алиасинга.

Разыменование int* обращается к объекту float через несовместимый тип и нарушает правила aliasing Опасность существует только на платформах, где sizeof(float) отличается от sizeof(int) `reinterpret_cast` создаёт отдельный объект `int` с тем же битовым представлением, поэтому чтение не обращается к исходному `float` Нарушение возможно лишь для отрицательных значений float Это стандартный определённый эквивалент `std::bit_cast<int>(f)`

Вопрос 7 из 30

Через какие типы стандарт разрешает просматривать объектное представление произвольного объекта как последовательность байтов?

Widget object;
auto bytes = std::as_bytes(std::span{&object, 1});

for (std::byte b : bytes)
    checksum = mix(checksum, std::to_integer<unsigned char>(b));

`bool` и любой enum с базовым типом unsigned char Только `signed char`; обычный char не имеет специального права доступа к представлению Любой целочисленный тип, если его размер равен размеру объекта Любой trivially copyable тип после приведения указателя к нему `char`, `unsigned char` и `std::byte`

Вопрос 8 из 30

Что делает std::bit_cast?

float value = 1.0f;
auto bits = std::bit_cast<std::uint32_t>(value);
static_assert(sizeof(float) == sizeof(std::uint32_t));

Меняет активный член union и начинает жизнь новой альтернативы Выполняет обычное числовое преобразование со сменой значения Возвращает ссылку другого типа на тот же объект без копирования битов Копирует битовое представление между trivially copyable типами одинакового размера Эквивалентен чтению активного объекта через ссылку целевого типа при совпадающем размере

Вопрос 9 из 30

Почему указатель после reinterpret_cast может быть неправильно выровнен?

std::byte buffer[16];
std::byte* address = buffer + 1;
auto* number = reinterpret_cast<std::uint64_t*>(address);
std::uint64_t x = *number; // адрес может нарушать alignof(uint64_t)

Проблема возможна лишь при приведении указателя на char Любой адрес памяти автоматически подходит для объекта любого выравнивания Требование выравнивания существует только для блоков, полученных через new Исходный адрес может не быть кратен `alignof` целевого типа Приведение округляет адрес вверх до подходящей границы и тем самым меняет указатель

Вопрос 10 из 30

Безопасно ли копировать trivially copyable T в массив bytes через memcpy и обратно?

static_assert(std::is_trivially_copyable_v<Header>);
std::array<std::byte, sizeof(Header)> bytes;
Header source{1, 2};
std::memcpy(bytes.data(), &source, sizeof source);
Header restored;
std::memcpy(&restored, bytes.data(), sizeof restored);

Разрешено только для полиморфного T с виртуальным деструктором Перенос объектного представления допустим лишь через активный член union Да: для trivially copyable T байты можно скопировать в подходящий массив и обратно Разрешено копировать только первый байт объекта Нет: memcpy всегда нарушает strict aliasing при работе с пользовательским типом

Вопрос 11 из 30

Каково поведение знакового переполнения int?

int x = std::numeric_limits<int>::max();
int y = x + 1; // знаковое переполнение

Значение насыщается на INT_MAX Компилятор обязан вернуть ноль Всегда исключение overflow_error Переход по модулю 2^N гарантирован Неопределённое поведение

Вопрос 12 из 30

Каково поведение переполнения unsigned?

unsigned x = std::numeric_limits<unsigned>::max();
unsigned y = x + 1u;
// y переходит к нулю по модулю 2^N

Результат определён по модулю 2^N для ширины беззнакового типа Операция выбрасывает стандартное исключение переполнения Переполнение даёт такое же неопределённое поведение, как у знакового типа Результат насыщается максимальным значением unsigned Поведение зависит от уровня оптимизации компилятора

Вопрос 13 из 30

Почему проверка `if (a + b < a)` опасна для знаковых int?

bool add_overflows(int a, int b) {
    return a + b < a;
}

std::cout << add_overflows(std::numeric_limits<int>::max(), 1);

Операция сравнения двух значений типа int сама по себе запрещена Условие истинно для любых a и b, независимо от переполнения Знаковое переполнение происходит до сравнения и уже приводит к UB Опасность появляется только при нулевом значении b При переполнении вычисление временно переходит к целым произвольной точности

Вопрос 14 из 30

Что происходит для `INT_MIN / -1` на типичном int, где результат не представим?

int value = std::numeric_limits<int>::min();
int result = value / -1;

std::cout << result;
// Математический результат не представим в int.

Неопределённое поведение Всегда 0 Только warning без семантической проблемы Результат INT_MAX Результат INT_MIN по модулю гарантирован

Вопрос 15 из 30

Почему сдвиг на количество бит, не меньше ширины типа, опасен?

std::uint32_t value = 1;
unsigned count = 32;
auto result = value << count; // count не меньше ширины типа

Результат определён как ноль для любого левого операнда Ограничение действует только для беззнаковых типов Счётчик сдвига вне диапазона ширины продвинутого левого операнда приводит к UB Процессор берёт остаток от ширины, и стандарт требует повторить аппаратное поведение Компилятор заменяет такой сдвиг циклом из безопасных единичных сдвигов

Вопрос 16 из 30

Почему компилятор может удалить проверку `if (p == nullptr)` после `*p`?

int read(const int* p) {
    int value = *p;
    if (p == nullptr)
        return 0;
    return value;
}

Аппаратно условие выполняется раньше разыменования независимо от порядка исходного кода После разыменования null временно обозначает специальный объект по адресу ноль Компилятор обязан считать любой указатель ненулевым и может удалять все проверки nullptr Удаление проверки допускается только в отладочной сборке, где данные о строках полнее На определённом пути корректное предыдущее разыменование возможно лишь при p != nullptr

Вопрос 17 из 30

Что означает as-if rule?

int compute(int* p) {
    int before = *p;
    expensive_work();
    int after = *p;
    return before + after;
}
// оптимизатор свободен преобразовать код, если наблюдаемое поведение сохраняется

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

Вопрос 18 из 30

Почему signed loop может быть оптимизирован с предположением отсутствия overflow?

Значение INT_MAX не известно компилятору до запуска Стандарт запрещает бесконечные циклы, поэтому счётчик не может перейти границу Поскольку signed overflow является UB, оптимизатор вправе рассуждать только о путях без него Оптимизатор обязан заменить int на unsigned и получить модульное поведение Процессоры не имеют флага переполнения для знаковой арифметики

Вопрос 19 из 30

Гарантирует ли volatile межпоточную синхронизацию?

Только на x86 Да, если -O0 Да, полностью заменяет mutex Да, если volatile-объект имеет тип bool и записывается одним машинным словом Нет, это не синхронизация

Вопрос 20 из 30

Почему ожидание `while (!ready) {}` небезопасно, если один поток пишет в обычный bool ready, а другой читает его без синхронизации?

Достаточно пометить ready как volatile, чтобы создать happens-before Это гонка данных; компилятор не обязан перечитывать ready так, как ожидает программист Цикл безопасен, если записывающий поток делает запись ровно один раз Пустое тело цикла само по себе всегда вызывает исключение времени выполнения Обычный bool атомарен только на 64-битных процессорах

Вопрос 21 из 30

Что обнаруживает UndefinedBehaviorSanitizer?

Проверяет все возможные формы UB во всех ветвях, даже если они не выполнялись в тестовом запуске Обнаруживает ошибки управления динамической памятью, но не арифметические и типовые нарушения Специализируется на межпоточных гонках и не проверяет операции одного потока Сообщает только о нарушениях, которые заканчиваются неперехваченным исключением C++ Инструментирует программу и обнаруживает поддерживаемую часть UB на реально выполненных путях

Вопрос 22 из 30

Почему программа, работающая при -O0 и ломающаяся при -O2, подозрительна на UB?

Любое различие доказывает ошибку оптимизатора и исключает дефект программы Отладочная сборка исправляет время жизни объектов и инициализирует всю память по стандарту Неопределённое поведение возникает только при включённой оптимизации Оптимизация использует предположения стандарта и может проявить ошибку, которую случайно скрывал код без оптимизации Флаг -O2 автоматически переключает язык на новую версию стандарта

Вопрос 23 из 30

Как fuzzing помогает искать UB?

Полностью заменяет статическую типизацию и анализ границ API Генерирует неожиданные входы, а санитайзеры помогают связать проявившийся сбой с опасной операцией Автоматически переписывает найденную операцию на безопасный вариант и продолжает тест Применим только к текстовым форматам и не умеет генерировать бинарные структуры Доказывает отсутствие UB для всего пространства входов после достаточно долгого запуска

Вопрос 24 из 30

Какие предупреждения компилятора полезны для lifetime/UB?

Ограничиться предупреждениями о неиспользуемых переменных, считая остальные классы ошибок задачей санитайзеров Нужно отключить warnings ради оптимизации Предупреждения видят все use-after-free Все warnings являются ложными Lifetime, uninitialized, aliasing и conversion warnings

Вопрос 25 из 30

Как минимизировать подозрительный UB-баг?

Зафиксировать уровень оптимизации, при котором симптом исчезает, и оставить исходный код без изменений Считать любое отличие оптимизаций ответом Сохранить сбой при минимальных данных и коде Добавить больше потоков и библиотек Переписать всё без воспроизведения

Вопрос 26 из 30

Почему “мы используем signed overflow ради скорости” плохой переносимый контракт?

Это безопасно для int32_t UB не обязано сохранять ожидаемый wraparound Флаг оптимизации всегда фиксирует модуль Signed overflow гарантирован быстрее unsigned Стандарт требует saturation

Вопрос 27 из 30

Как span снижает риск UB по сравнению с голым T*?

span сериализует параллельный доступ к диапазону и устраняет гонки данных span владеет памятью и автоматически продлевает жизнь исходного контейнера Оператор `span::operator[]` во всех версиях C++ обязан проверять индекс и бросать исключение span переносит вместе адрес и длину, поэтому границы можно выражать и проверять в одном объекте span сохраняет копию элементов при каждом построении и потому не может стать висячим

Вопрос 28 из 30

Когда флаг `-fno-strict-aliasing` может быть временным компромиссом?

// Временный режим сборки старого модуля:
target_compile_options(legacy_codec PRIVATE -fno-strict-aliasing)

// Одновременно включены UBSan и план замены punning-кода
// на memcpy/std::bit_cast с отдельными тестами формата.

Чтобы убрать необходимость тестов Как временная мера при локализации legacy-нарушений aliasing Как универсальный способ сделать любой type punning стандартным Чтобы разрешить use-after-free Включить флаг для ускорения всех операций с указателями, даже в корректном коде без aliasing-нарушений

Вопрос 29 из 30

Почему fast path без проверки должен иметь доказанное предусловие?

Предусловия не относятся к API Проверки всегда бесплатны UB локализовано одной функцией Fast path выполняется только в тестах Иначе редкий вход даёт UB всему процессу

Вопрос 30 из 30

Какой API безопаснее для чтения бинарного поля?

Молча использовать порядок байтов хоста для любого внешнего формата Привести произвольный адрес пакета к указателю на структуру и читать поля напрямую Принимать `span<const std::byte>`, проверять длину и переносить представление через memcpy или bit_cast Принимать нетипизированный адрес без размера и считать буфер достаточным Читать поле до проверки длины, полагаясь на padding структуры

Ответьте на все 30 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу