Установка дополнительных битов в bool делает его истинным и ложным одновременно

В C++ битовое представление (и даже размер) bool определяется реализацией; обычно он реализован как тип размера char, принимающий 1 или 0 в качестве возможных значений.

Если вы установите для него значение, отличное от допустимого (в данном конкретном случае, сменив bool на char и изменив его битовое представление), вы нарушите правила языка, так что может случиться что угодно. В частности, в стандарте прямо указано, что «сломанный» bool может вести себя как true, так и false (или ни true, ни false) одновременно:

Using a bool value in ways described by this International Standard as “undefined,” such as by examining the value of an uninitialized automatic object, might cause it to behave as if it is neither true nor false

(C++11, [basic.fundamental], примечание 47)

В данном конкретном случае Вы можете видеть, как это закончилось в этой странной ситуации: первый if компилируется в

    movzx   eax, BYTE PTR [rbp-33]
    test    al, al
    je      .L22

который загружает T в eax (с нулевым расширением) и пропускает печать, если все нулевое; следующий, если вместо этого

    movzx   eax, BYTE PTR [rbp-33]
    xor     eax, 1
    test    al, al
    je      .L23

Тест if (T == false) преобразуется в if (T^1), который переворачивает только младший бит. Это было бы нормально для действительного bool, но для вашего «сломанного» это не подходит.

Обратите внимание, что эта причудливая последовательность создается только при низких уровнях оптимизации; на более высоких уровнях это обычно сводится к нулевой/ненулевой проверке, и последовательность, подобная вашей, скорее всего, станет одна тестовая/условная ветвь. Вы все равно получите странное поведение в других контекстах, например. при суммировании значений bool с другими целыми числами:

int foo(bool b, int i) {
    return i + b;
}

становится

foo(bool, int):
        movzx   edi, dil
        lea     eax, [rdi+rsi]
        ret

где dil «доверено» быть 0/1.

Если ваша программа целиком на C++, то решение простое: не ломайте bool значения таким образом, избегайте возни с их битовым представлением, и все будет хорошо; в частности, даже если вы присваиваете значение из целого числа bool, компилятор выдаст необходимый код, чтобы убедиться, что результирующее значение является допустимым bool, поэтому ваш bool T = 3 действительно безопасен, а T в конечном итоге окажется с true во внутренностях .

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

Обновление о стороне проблемы, связанной с Fortran/совместимостью

Disclaimer all I know of Fortran is what I read this morning on standard documents, and that I have some punched cards with Fortran listings that I use as bookmarks, so go easy on me.

Во-первых, такого рода языковая совместимость не является частью языковых стандартов, а является частью платформы ABI. Поскольку мы говорим о Linux x86-64, соответствующий документ — System V x86-64 ABI.

Во-первых, нигде не указано, что тип C _Bool (который определяется как такой же, как C++ bool в примечании 3.1.2 †) имеет какую-либо совместимость с Fortran LOGICAL; в частности, в 9.2.2 таблица 9.2 указывает, что «обычный» LOGICAL отображается в signed int. О типах TYPE*N сказано, что

The “TYPE*N” notation specifies that variables or aggregate members of type TYPE shall occupy N bytes of storage.

(там же.)

Для LOGICAL*1 нет явно указанного эквивалентного типа, и это понятно: это даже не стандарт; действительно, если вы попытаетесь скомпилировать программу на Фортране, содержащую LOGICAL*1 в режиме, совместимом с Fortran 95, вы получите предупреждения об этом, как от ifort

./example.f90(2): warning #6916: Fortran 95 does not allow this length specification.   [1]

    logical*1, intent(in) :: x

------------^

и с усилием

./example.f90:2:13:
     logical*1, intent(in) :: x
             1
Error: GNU Extension: Nonstandard type declaration LOGICAL*1 at (1)

так уже смешались воды; поэтому, объединив два приведенных выше правила, я бы выбрал signed char, чтобы быть в безопасности.

Однако: ABI также указывает:

The values for type LOGICAL are .TRUE. implemented as 1 and .FALSE. implemented as 0.

Итак, если у вас есть программа, которая хранит что-либо, кроме 1 и 0, в значении LOGICAL, вы уже не соответствуете спецификации на стороне Fortran! Ты говоришь:

A fortran logical*1 has same representation as bool, but in fortran if bits are 00000011 it is true, in C++ it is undefined.

Это последнее утверждение неверно, стандарт Fortran не зависит от представления, а ABI прямо говорит об обратном. Действительно, вы можете легко увидеть это в действии с помощью проверка вывода gfort для LOGICAL сравнения:

integer function logical_compare(x, y)
    logical, intent(in) :: x
    logical, intent(in) :: y
    if (x .eqv. y) then
        logical_compare = 12
    else
        logical_compare = 24
    end if
end function logical_compare

становится

logical_compare_:
        mov     eax, DWORD PTR [rsi]
        mov     edx, 24
        cmp     DWORD PTR [rdi], eax
        mov     eax, 12
        cmovne  eax, edx
        ret

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

Еще интереснее: независимо от того, что говорит ABI, ifort по умолчанию использует нестандартное представление для LOGICAL; это объясняется в документации по переключателю -fpscomp logicals, в которой также указаны некоторые интересные подробности о LOGICAL и межъязыковой совместимости:

Specifies that integers with a non-zero value are treated as true, integers with a zero value are treated as false. The literal constant .TRUE. has an integer value of 1, and the literal constant .FALSE. has an integer value of 0. This representation is used by Intel Fortran releases before Version 8.0 and by Fortran PowerStation.

The default is fpscomp nologicals, which specifies that odd integer values (low bit one) are treated as true and even integer values (low bit zero) are treated as false.

The literal constant .TRUE. has an integer value of -1, and the literal constant .FALSE. has an integer value of 0. This representation is used by Compaq Visual Fortran. The internal representation of LOGICAL values is not specified by the Fortran standard. Programs which use integer values in LOGICAL contexts, or which pass LOGICAL values to procedures written in other languages, are non-portable and may not execute correctly. Intel recommends that you avoid coding practices that depend on the internal representation of LOGICAL values.

(выделение добавлено)

Теперь внутреннее представление LOGICAL обычно не должно быть проблемой, поскольку, насколько я понимаю, если вы играете «по правилам» и не пересекаете языковые границы, вы не заметите. Для стандартной программы нет «прямого преобразования» между INTEGER и LOGICAL; единственный способ, который я вижу, вы можете засунуть INTEGER в LOGICAL вроде бы TRANSFER, который по своей сути не переносим и не дает никаких реальных гарантий, или нестандартное преобразование INTEGER <-> LOGICAL по заданию.

Последний задокументировано по gfort всегда приводит к ненулевому -> .TRUE., нулю -> .FALSE. и ты можешь видеть, который во всех случаях генерирует код, чтобы это произошло (даже если это запутанный код в случае ifort с устаревшим представлением), поэтому вы не можете засунуть произвольное целое число в LOGICAL таким образом.

logical*1 function integer_to_logical(x)
    integer, intent(in) :: x
    integer_to_logical = x
    return
end function integer_to_logical

integer_to_logical_:
        mov     eax, DWORD PTR [rdi]
        test    eax, eax
        setne   al
        ret

Обратное преобразование для LOGICAL*1 представляет собой прямое целое с нулевым расширением (gfort), поэтому для соблюдения контракта в документации, указанной выше, явно ожидается, что значение LOGICAL будет равно 0 или 1.

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

Итак, вкратце: избегайте помещать INTEGER данные в LOGICAL значения, так как это плохо даже в Fortran, и убедитесь, что используете правильный флаг компилятора, чтобы получить ABI-совместимое представление для логических значений, и взаимодействие с C/C++ должно быть в порядке. . Но для дополнительной безопасности я бы просто использовал простой char на стороне C++.

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

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

Вы, наверное, где-то слышали, что «ноль — это ложь», а «ненулевое — это правда». Это справедливо, когда вы придерживаетесь параметров языка, статически преобразовывая int в bool или наоборот.

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

Просто не делай этого.

Вам не решать, как bool хранится в памяти. Это зависит от компилятора. Если вы хотите изменить значение bool, либо присвойте true/false, либо присвойте целое число и используйте соответствующие механизмы преобразования, предоставляемые C++.

Стандарт C++ фактически давал конкретный призыв к тому, что использование bool таким образом непослушно, плохо и зло («Использование значения bool способами, описанными в этом документе как «неопределенное», например, путем проверки значения неинициализированного автоматического объекта, может привести к тому, что он будет вести себя так, как будто он не является ни true, ни false».), хотя это было удалено в C++20 по редакционным причинам.