Допускает ли стандарт C ++ неинициализированный bool для сбоя программы? - PullRequest
Новая
       114

Допускает ли стандарт C ++ неинициализированный bool для сбоя программы?

0 голосов
/ 10 января 2019

Я знаю, что "неопределенное поведение" в C ++ может в значительной степени позволить компилятору делать все, что он хочет. Однако меня удивил сбой, так как я предположил, что код достаточно безопасен.

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

Я перепробовал несколько вещей, чтобы воспроизвести проблему и максимально упростить ее. Вот фрагмент функции с именем Serialize, которая принимает параметр bool и копирует строку true или false в существующий целевой буфер.

Если бы эта функция была в обзоре кода, не было бы никакого способа сказать, что она могла бы аварийно завершиться, если бы параметр bool был неинициализированным значением? 

// Zero-filled global buffer of 16 characters
char destBuffer[16];

void Serialize(bool boolValue) {
    // Determine which string to print based on boolValue
    const char* whichString = boolValue ? "true" : "false";

    // Compute the length of the string we selected
    const size_t len = strlen(whichString);

    // Copy string into destination buffer, which is zero-filled (thus already null-terminated)
    memcpy(destBuffer, whichString, len);
}

Если этот код выполняется с оптимизацией clang 5.0.0 +, он может / может дать сбой.

Ожидаемый троичный оператор boolValue ? "true" : "false" выглядел достаточно безопасным для меня, я предполагал: «Какое бы значение мусора ни было в boolValue, не имеет значения, поскольку оно все равно будет иметь значение true или false».

У меня настроен Пример компилятора , который показывает проблему при разборке, вот полный пример. Примечание. Чтобы воспроизвести проблему, я нашел сработавшую комбинацию с использованием Clang 5.0.0 с оптимизацией -O2. 

#include <iostream>
#include <cstring>

// Simple struct, with an empty constructor that doesn't initialize anything
struct FStruct {
    bool uninitializedBool;

   __attribute__ ((noinline))  // Note: the constructor must be declared noinline to trigger the problem
   FStruct() {};
};

char destBuffer[16];

// Small utility function that allocates and returns a string "true" or "false" depending on the value of the parameter
void Serialize(bool boolValue) {
    // Determine which string to print depending if 'boolValue' is evaluated as true or false
    const char* whichString = boolValue ? "true" : "false";

    // Compute the length of the string we selected
    size_t len = strlen(whichString);

    memcpy(destBuffer, whichString, len);
}

int main()
{
    // Locally construct an instance of our struct here on the stack. The bool member uninitializedBool is uninitialized.
    FStruct structInstance;

    // Output "true" or "false" to stdout
    Serialize(structInstance.uninitializedBool);
    return 0;
}

Проблема возникает из-за оптимизатора: было достаточно умно сделать вывод, что строки «истина» и «ложь» различаются только по длине на 1. Поэтому вместо реального вычисления длины он использует значение самого bool , который должен технически равен 0 или 1, и выглядит так: 

const size_t len = strlen(whichString); // original code
const size_t len = 5 - boolValue;       // clang clever optimization

Хотя это, так сказать, «умно», мой вопрос таков: Позволяет ли стандарт C ++ компилятору предполагать, что bool может иметь только внутреннее числовое представление «0» или «1» и использовать его таким образом?

Или это случай, определенный реализацией, и в этом случае реализация предполагала, что все ее значения bool будут содержать только 0 или 1, а любое другое значение является неопределенной территорией поведения?

Ответы [ 5 ]

0 голосов
/ 10 января 2019

Резюмируя ваш вопрос, вы спрашиваете: позволяет ли стандарт C ++ компилятору предполагать, что bool может иметь только внутреннее числовое представление '0' или '1' и использовать его таким образом?

Стандарт ничего не говорит о внутреннем представлении bool. Он определяет только то, что происходит при приведении bool к int (или наоборот). Главным образом, из-за этих интегральных преобразований (и того факта, что люди довольно сильно на них полагаются), компилятор будет использовать 0 и 1, но это не обязательно (хотя он должен учитывать ограничения любого ABI более низкого уровня, который он использует ).

Итак, компилятор, когда он видит bool, имеет право считать, что указанный bool содержит один из битовых шаблонов 'true' или 'false' и делать все, что ему нравится. Таким образом, если значения true и false равны 1 и 0 соответственно, компилятору действительно разрешено оптимизировать strlen до 5 - <boolean value>. Другие забавные поведения возможны!

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

  • Ваш код работает так, как вы ожидали
  • Ваш код не работает в случайное время
  • Ваш код вообще не запускается.

См. Что каждый программист должен знать о неопределенном поведении

0 голосов
/ 10 января 2019

Да, ISO C ++ допускает (но не требует) реализации, чтобы сделать этот выбор.

Но также обратите внимание, что ISO C ++ позволяет компилятору генерировать код, который вылетает намеренно (например, с недопустимой инструкцией), если программа встречает UB, например, как способ помочь вам найти ошибки. (Или потому, что это DeathStation 9000. Строго соответствующего соответствия недостаточно, чтобы реализация C ++ была полезна для любых реальных целей). Таким образом, ISO C ++ позволит компилятору создавать сбой asm (по совершенно разным причинам) даже в аналогичном коде, который читает неинициализированный uint32_t. Даже при том, что это должен быть тип с фиксированной компоновкой без ловушки представления.

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

Вы компилируете для x86-64 System V ABI , который указывает, что bool как аргумент функции в регистре представлен битовыми комбинациями false=0 и true=1 в младших 8 битах регистра 1 . В памяти bool является однобайтовым типом, который снова должен иметь целочисленное значение 0 или 1.

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

ISO C ++ не определяет его, но это решение ABI широко распространено, потому что оно делает преобразование bool-> int дешевым (просто с нулевым расширением) . Мне не известны никакие ABI, которые не позволяют компилятору принимать 0 или 1 для bool для любой архитектуры (не только для x86). Это позволяет оптимизировать, например, !mybool с xor eax,1, чтобы перевернуть младший бит: Любой возможный код, который может перевернуть бит / целое число / число от 0 до 1 в одной инструкции CPU . Или компилирование a&&b в побитовое И для bool типов. Некоторые компиляторы действительно используют логические значения как 8-битные в компиляторах. Операции над ними неэффективны? .

Как правило, правило «как если» позволяет компилятору использовать преимущества истинных на целевой платформе, компилируемой для , поскольку конечный результат будет исполняемым код, который реализует то же внешне видимое поведение, что и исходный код C ++. (Со всеми ограничениями, которые Undefined Behavior накладывает на то, что на самом деле является «внешне видимым»: не с помощью отладчика, а из другого потока в правильно сформированной / легальной программе C ++.)

Компилятору определенно разрешено в полной мере использовать гарантию ABI в своем коде поколения и создавать код, подобный тому, который вы нашли, который оптимизирует strlen(whichString) до
5U - boolValue. (Кстати, эта оптимизация довольно умная, но, возможно, близорукая по сравнению с ветвлением и встраиванием memcpy в качестве хранилищ непосредственных данных 2 .)

Или компилятор мог бы создать таблицу указателей и проиндексировать ее целочисленным значением bool, снова предполагая, что это 0 или 1. ( Эта возможность - то, что @ ответ Бармара предложил .)

Ваш конструктор __attribute((noinline)) с включенной оптимизацией привел к тому, что Clang просто загрузил байт из стека для использования в качестве uninitializedBool. Он выделил место для объекта в main с push rax (что меньше и по разным причинам примерно так же эффективно, как sub rsp, 8), поэтому любой мусор, который был в AL при входе в main, является значением, которое он использовал для uninitializedBool. Вот почему вы на самом деле получили значения, которые были не просто 0.

5U - random garbage может легко переносить большие значения без знака, что приводит к тому, что memcpy попадает в неотображенную память. Место назначения находится в статическом хранилище, а не в стеке, поэтому вы не перезаписываете адрес возврата или что-то еще.

Другие реализации могут делать разные варианты, например, false=0 и true=any non-zero value. Тогда, вероятно, clang не создаст код, который вылетает для этого конкретного экземпляра UB. (Но это все равно было бы разрешено, если бы захотелось.) Я не знаю каких-либо реализаций, которые выбирали бы что-нибудь другое, что делает x86-64 для bool, но стандарт C ++ допускает многие вещи, которые никто не делает или даже хотелось бы сделать на оборудовании что-нибудь похожее на современные процессоры.

ISO C ++ оставляет неуказанным, что вы найдете, когда вы исследуете или изменяете объектное представление bool. (Например, memcpy вставив bool в unsigned char, что вам разрешено делать, потому что char* может псевдонимом чего угодно. И unsigned char гарантированно не содержит битов заполнения, поэтому стандарт C ++ формально разрешает Вы hexdump представления объектов без UB. Приведение указателя для копирования представления объекта, конечно, отличается от присваивания char foo = my_bool, конечно, поэтому булеванизация 0 или 1 не произойдет, и вы получите необработанное представление объекта.)

Вы частично"скрыли" UB на этом пути выполнения от компилятора с помощью noinline. Однако, даже если он не встроен, межпроцедурная оптимизация может сделать версию функции зависимой от определения другой функции. (Во-первых, clang создает исполняемый файл, а не разделяемую библиотеку Unix, где может происходить взаимное расположение символов. Во-вторых, определение внутри определения class{}, поэтому все единицы перевода должны иметь одно и то же определение. Как и в случае ключевого слова inline. )

Таким образом, компилятор может выдавать просто ret или ud2 (недопустимая инструкция) в качестве определения для main, потому что путь выполнения, начинающийся с main, неизбежно встречает неопределенное поведение. (который компилятор может видеть во время компиляции, если он решил следовать по пути через не встроенный конструктор.)

Любая программа, которая встречает UB, полностью не определена в течение всего ее существования. Но UB внутри функции или ветви if(), которая никогда не запускается, не портит остальную часть программы. На практике это означает, что компиляторы могут решить выдать недопустимую инструкцию, или ret, или не излучать что-либо и попасть в следующий блок / функцию, для всего базового блока, который может быть доказан во время компиляции, чтобы содержать или привести к UB.

GCC и Clang на практике do фактически иногда выдают ud2 на UB, вместо того, чтобы даже пытаться сгенерировать код для путей выполнения, которые не имеют смысла. Или для таких случаев, как выпадая из конца не void функции, gcc иногда пропускает инструкцию ret. Если вы думали, что «моя функция просто вернется с мусором в RAX», вы сильно ошибаетесь. Современные компиляторы C ++ больше не рассматривают язык как переносимый язык ассемблера. Ваша программа действительно должна быть верной C ++, не делая предположений о том, как автономная не встроенная версия вашей функции может выглядеть в asm.

Еще один забавный пример: Почему при выравнивании доступа к памяти mmap иногда возникает ошибка на AMD64? . x86 не ошибается на невыровненных целых числах, верно? Так почему бы смещение uint16_t* было проблемой? Потому что alignof(uint16_t) == 2 и нарушение этого предположения приводило к segfault при автоматической векторизации с SSE2.

См. Также Что каждый программист C должен знать о неопределенном поведении # 1/3 , статья разработчика Clang.

Ключевой момент: если компилятор заметил UB во время компиляции, он может «сломать» (испустить удивительный asm) путь через ваш код, который вызывает UB, даже если он нацелен на ABI, где есть какой-либо битовый шаблон является допустимым представлением объекта для bool.

Ожидайте полной враждебности ко многим ошибкам со стороны программиста, особенно о том, о чем предупреждают современные компиляторы. Вот почему вы должны использовать -Wall и исправлять предупреждения. C ++ не является дружественным к пользователю языком, и что-то в C ++ может быть небезопасным, даже если это будет безопасно в asm для цели, для которой вы компилируете. (например, переполнение со знаком - это UB в C ++, и компиляторы предполагают, что этого не произойдет, даже при компиляции для дополнения x86 к 2, если вы не используете clang/gcc -fwrapv.)

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

Не быть слишком драматичным; часто компиляторы позволяют вам сойтись с некоторыми вещами и генерировать код, как вы ожидаете, даже когда что-то не так. Но, возможно, это будет проблемой в будущем, если разработчики компиляторов реализуют некоторую оптимизацию, которая получает больше информации о диапазонах значений (например, переменная неотрицательна, возможно, позволяя оптимизировать расширение знака для свободного расширения нуля на x86- 64). Например, в текущих gcc и clang выполнение tmp = a+INT_MIN не оптимизирует a<0 как всегда ложное, только то, что tmp всегда отрицательно. (Потому что INT_MIN + a=INT_MAX отрицателен для этой цели дополнения 2, а a не может быть выше этого значения.)

Таким образом, gcc / clang в настоящее время не возвращается для получения информации о диапазоне для входных данных вычисления, а только по результатам, основанным на предположении о не переполнении со знаком: пример для Godbolt . Я не знаю, намеренно ли "пропущена" эта оптимизация во имя удобства для пользователя или как.

Также обратите внимание, что реализации (также известные как компиляторы) позволяют определять поведение, которое ISO C ++ оставляет неопределенным . Например, все компиляторы, которые поддерживают встроенные функции Intel (например, _mm_add_ps(__m128, __m128) для ручной векторизации SIMD), должны разрешать формирование неправильно выровненных указателей, что является UB в C ++, даже если вы не разыменовываете их. __m128i _mm_loadu_si128(const __m128i *) выполняет не выровненные нагрузки, принимая неправильное __m128i* arg, а не void* или char*. Является ли `reinterpret_cast`ing между указателем аппаратного вектора и соответствующим типом неопределенным поведением?

GNU C / C ++ также определяет поведение сдвига влево отрицательного числа со знаком (даже без -fwrapv) отдельно от обычных правил UB со знаком переполнения. ( Это UB в ISO C ++ , в то время как правое смещение чисел со знаком определяется реализацией (логическое или арифметическое); реализации хорошего качества выбирают арифметику на HW, которая имеет арифметические правые сдвиги, но ISO C ++ не делает уточнить). Это задокументировано в разделе Integer руководства GCC вместе с определением поведения, определяемого реализацией, которое стандарты C требуют, чтобы реализации определяли так или иначе.

Определенно есть проблемы с качеством реализации, о которых заботятся разработчики компиляторов; они обычно не пытаются сделать компиляторы преднамеренно враждебными, но использование всех пробелов UB в C ++ (кроме тех, которые они выбирают для оптимизации) иногда может быть почти неразличимым.

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

( Другие ABI do здесь делают разные варианты . Некоторые требуют, чтобы узкие целочисленные типы были расширены нулями или знаками для заполнения регистра при передаче или возвращении из функций, как MIPS64 и PowerPC64. См. последний раздел этого ответа x86-64, который сравнивается с теми более ранними ISA .)

Например, вызывающий абонент мог вычислить a & 0x01010101 в RDI и использовать его для чего-то еще, прежде чем вызвать bool_func(a&1). Вызывающий может оптимизировать &1, потому что он уже сделал это с младшим байтом как часть and edi, 0x01010101, и он знает, что вызываемый абонент должен игнорировать старшие байты.

Или, если bool передан как 3-й аргумент, возможно, вызывающая программа, оптимизирующая код по размеру, загружает его с mov dl, [mem] вместо movzx edx, [mem], сохраняя 1 байт за счет ложной зависимости от старого значения RDX (или другой эффект частичного регистра, в зависимости от модели процессора). Или для первого аргумента mov dil, byte [r10] вместо movzx edi, byte [r10], потому что оба в любом случае требуют префикса REX.

Вот почему Clang испускает movzx eax, dil в Serialize вместо sub eax, edi. (Для целочисленных аргументов clang нарушает это правило ABI, вместо этого в зависимости от недокументированного поведения gcc и clang до нуля или от знака расширяют узкие целые числа до 32 бит. Требуется ли расширение знака или нуля при добавлении 32-битного смещения к указатель для x86-64 ABI? Поэтому мне было интересно увидеть, что это не делает то же самое для bool.)

Сноска 2: После ветвления у вас будет только 4-байтовое mov -обратное хранилище или 4-байтовое + 1-байтовое хранилище. Длина указана в значениях ширины магазина + смещения.

OTOH, glibc memcpy выполнит две 4-байтовых загрузки / сохранения с перекрытием, зависящим от длины, так что это действительно в конечном итоге делает все это свободным от условных ветвей в логическом значении. См. L(between_4_7): блок в memcpy / memmove glibc. Или, по крайней мере, используйте тот же способ для логического значения в ветвлении memcpy, чтобы выбрать размер куска.

При встраивании можно использовать 2x mov -immediate + cmov и условное смещение или оставить строковые данные в памяти.

Или, если выполняется настройка для Intel Ice Lake ( с функцией Fast Short REP MOV ), фактическая rep movsb может быть оптимальной. glibc memcpy может начать использовать rep movsb для небольших размеров на процессорах с этой функцией, сохраняя большое количество ветвлений.

Инструменты для обнаружения UB и использования неинициализированных значений

В gcc и clang вы можете скомпилировать с -fsanitize=undefined, чтобы добавить инструментарий времени выполнения, который будет предупреждать или выдавать ошибку в UB, которая происходит во время выполнения. Это не поймает унифицированные переменные, хотя. (Поскольку он не увеличивает размеры шрифта, чтобы освободить место для «неинициализированного» бита).

См. https://developers.redhat.com/blog/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/

Чтобы найти использование неинициализированных данных, есть утилита Address Sanitizer и Memory Sanitizer в clang / LLVM. https://github.com/google/sanitizers/wiki/MemorySanitizer показывает примеры clang -fsanitize=memory -fPIE -pie обнаружения операций чтения неинициализированной памяти. Это может работать лучше, если вы компилируете без оптимизации, поэтому все операции чтения переменных в конечном итоге фактически загружаются из памяти в asm. Они показывают, что он используется в -O2 в случае, когда нагрузка не оптимизируется. Я сам не пробовал. (В некоторых случаях, например, не инициализируя аккумулятор перед суммированием массива, clang -O3 будет выдавать код, который суммируется в векторный регистр, который он никогда не инициализировал. Так что с оптимизацией вы можете иметь случай, когда нет чтения памяти, связанной с UB Но -fsanitize=memory изменяет сгенерированный asm и может привести к проверке этого.)

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

MemorySanitizer реализует подмножество функций, найденных в Valgrind (инструмент Memcheck).

Это должно работать для этого случая, потому что вызов glibc memcpy с length, рассчитанным из неинициализированной памяти, приведет (внутри библиотеки) к ответвлению на основе length. Если бы в нем была встроенная версия без ответвлений, в которой использовались cmov, индексирование и два хранилища, это могло бы не сработать.

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

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

0 голосов
/ 10 января 2019

Разрешается, чтобы bool содержал только значения 0 или 1, и сгенерированный код может предполагать, что он будет содержать только одно из этих двух значений. Код, сгенерированный для троичной переменной в присваивании, может использовать значение в качестве индекса в массиве указателей на две строки, то есть его можно преобразовать во что-то вроде: 

     // the compile could make asm that "looks" like this, from your source
const static char *strings[] = {"false", "true"};
const char *whichString = strings[boolValue];

Если boolValue неинициализирован, он может содержать любое целочисленное значение, что приведет к доступу за пределы массива strings.

0 голосов
/ 10 января 2019

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

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

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

NB. Ответ на вопрос «Может ли неопределенное поведение вызвать _____?» всегда "да". Это буквально определение неопределенного поведения.

0 голосов
/ 10 января 2019

Компилятору разрешается предполагать, что логическое значение, переданное в качестве аргумента, является допустимым логическим значением (то есть тем, которое было инициализировано или преобразовано в true или false). Значение true не обязательно должно совпадать с целым числом 1 - действительно, могут быть различные представления true и false - но параметр должен быть некоторым допустимым представлением одного из этих двух значений где «допустимое представление» определяется реализацией.

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

50) Использование значения bool способами, описанными в этом международном стандарте как «неопределенные», например, путем проверки значения неинициализированного автоматического объекта, может привести к тому, что он будет вести себя так, как если бы он не был ни истинным, ни ложным. (сноска к пункту 6 раздела 6.9.1, Основные типы)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.

Похожие темы

...