Да, ISO C ++ позволяет (но не требует) реализации сделать этот выбор.
Но также обратите внимание, что ISO C ++ позволяет компилятору генерировать код, который вылетает намеренно (например, с недопустимой инструкцией), если программа встречает UB, например, как способ помочь вам найти ошибки. (Или потому, что это DeathStation 9000. Строго соответствующего соответствия недостаточно для того, чтобы реализация C ++ была полезна для любых реальных целей). Таким образом, ISO C ++ позволил бы компилятору создавать сбой asm (по совершенно другим причинам) даже в аналогичном коде, который читает неинициализированный uint32_t
. Даже при том, что это должен быть тип с фиксированной компоновкой без представления ловушек.
Это интересный вопрос о том, как работают реальные реализации, но помните, что даже если бы ответ был другим, ваш код все равно был бы небезопасным, потому что современный C ++ не является переносимой версией ассемблера.
Вы компилируете для x86-64 System V ABI , который указывает, что a bool
как функция arg в регистре представлена битовыми комбинациями false=0
иtrue=1
в младших 8 битах регистра 1 . В памяти bool
- это 1-байтовый тип, который снова должен иметь целочисленное значение 0 или 1.
(ABI - это набор вариантов реализации, с которыми согласуются компиляторы для одной и той же платформы, чтобы они могли создавать код, который вызывает функции друг друга, включая размеры типов, правила структурирования и соглашения о вызовах.)
ISO C ++ не определяет его, но это решение ABI широко распространено, потому что оно делает преобразование bool-> int дешевым (просто с нулевым расширением) . Я не знаю ни одного ABI, которые не позволяют компилятору принимать 0 или 1 bool
для любой архитектуры (не только x86). Это позволяет оптимизировать, например, !mybool
с помощью xor eax,1
переворачивания младшего бита: любой возможный код, который может переворачивать бит / целое число / bool между 0 и 1 в одной инструкции CPU . Или компилирование a&&b
в побитовое И для bool
типов. Некоторые компиляторы действительно используют булевы значения как 8-битные в компиляторах. Операции на них неэффективны? ,
В общем, правило «как если» позволяет компилятору использовать преимущества, которые являются истинными на целевой компилируемой платформе , потому что конечным результатом будет исполняемый код, который реализует то же внешне видимое поведение, что и исходный код C ++. (Со всеми ограничениями, которые Undefined Behavior накладывает на то, что на самом деле является «внешне видимым»: не с помощью отладчика, а из другого потока в правильно сформированной / легальной программе C ++.)
Компилятор, безусловно , позволило в полной мере воспользовался гарантией ABI в его код-ген, и сделать код , как вы нашли , который оптимизирует strlen(whichString)
к
5U - boolValue
. (Кстати, эта оптимизация довольно умная, но может быть недальновидной, а не разветвленной и встроенной memcpy
как хранилище непосредственных данных 2. )
Или компилятор мог бы создать таблицу указателей и проиндексировать ее целочисленным значением bool
, опять же, предполагая, что это 0 или 1. ( Эта возможность - то, что предложил ответ @ Barmar .)
Ваш __attribute((noinline))
конструктор с включенной оптимизацией привел к лягушке, просто загружающей байт из стека для использования в качестве uninitializedBool
. Он освободил место для объекта в main
with 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 ++ оставляет неопределенным, что вы найдете, когда изучите или измените объектное представление abool
. (Например, с 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
неизбежно встречает Undefined Behavior. (Что может видеть компилятор во время компиляции, если он решил следовать по пути через не встроенный конструктор.)
Любая программа, которая сталкивается с UB, полностью не определена в течение всего ее существования. Но UB внутри функции или if()
ветви, которая фактически никогда не запускается, не повреждает остальную часть программы. На практике это означает, что компиляторы могут решить выдать недопустимую инструкцию, или a ret
, или не выдавать что-либо и попасть в следующий блок / функцию, для всего базового блока, который может быть доказан во время компиляции, чтобы содержать или привести к UB.
GCC и Clang на практике же на самом деле иногда выделяют ud2
на УБ, а даже пытается генерировать код для путей выполнения , которые не имеют никакого смысла. Или для случаев, таких как падение 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*
аргумент, а не void*
или char*
. Является ли `reinterpret_cast`ing между аппаратным указателем вектора и соответствующим типом неопределенным поведением?
GNU C / C ++ также определяет поведение сдвига влево отрицательного числа со знаком (даже без -fwrapv
) отдельно от обычных правил UB со знаком переполнения. ( Это UB в ISO C ++ , в то время как правое смещение чисел со знаком определяется реализацией (логическое или арифметическое); реализации хорошего качества выбирают арифметику на HW, которая имеет арифметические правые сдвиги, но ISO C ++ не определяет). Это задокументировано в разделе Integer руководства GCC вместе с определением поведения, определяемого реализацией, которое стандарты C требуют, чтобы реализации определяли так или иначе.
Определенно есть проблемы с качеством реализации, о которых заботятся разработчики компиляторов; они, как правило, не пытаются сделать компиляторы намеренно враждебными, но использование всех пробелов UB в C ++ (кроме тех, которые они выбирают для оптимизации) иногда может быть почти неразличимым.
Сноска 1 : старшие 56 битов могут быть мусором, который вызывающий должен игнорировать, как обычно для типов, более узких, чем регистр.
( Другие АБИСЫ сделать сделать различные варианты здесь . Некоторые из них требуют целых узких типов быть нулевыми или знаковым расширением для заполнения регистра при передаче или вернулись из функций, таких как MIPS64 и PowerPC64 см. Последний раздел этого x86-64 ответа который сравнивается с теми более ранними МСА .)
Например, вызывающий абонент мог рассчитать 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.
Именно поэтому лязг излучает movzx eax, dil
в Serialize
, вместо sub eax, edi
. (Для целочисленных аргументов clang нарушает это правило ABI, вместо этого в зависимости от недокументированного поведения gcc и clang до нуля или знака расширяет узкие целые числа до 32 бит. Требуется ли расширение знака или нуля при добавлении 32-битного смещения к указателю для ABI x86-64?
Так что мне было интересно увидеть, что он не делает то же самое для 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 информация о том, что было дополнением и что на самом деле является частью значения, была потеряна.