Is it UB to write values other than 0 or 1 in a bool? If yes, how do they compare?

Question

Consider the program below.

All comparisons are true with a recent gcc but only the value 1 compares equal with the Visual Studio commandline compiler v. 19.16.27031.1 for x86.

I believe that it's generally OK to write into PODs through char pointers; but is there wording in the standard about writing funny values into bool variables? If it is allowed, is there wording about the behavior in comparisons?

#include <iostream>
using namespace std;

void f()
{
   if(sizeof(bool) != 1)
   {
      cout << "sizeof(bool) != 1\n";
      return;
   }

  bool b;

  *(char *)&b = 1;
  if(b == true) { cout << (int) *(char *)&b  << " is true\n"; }

  *(char *)&b = 2;
  if(b == true) { cout << (int) *(char *)&b  << " is true\n"; }

  *(char *)&b = 3;
  if(b == true) { cout << (int) *(char *)&b  << " is true\n"; }
}

int main()
{
    f();
}

P.S. gcc 8.3 uses a test instruction to effectively check for non-zero while gcc 9.1 explicitly compares with 1, making only that comparison true. Perhaps this godbolt link works.

Answer 1

No. This is not OK.

Writting arbitrary data in a bool is much UB (see What is the strict aliasing rule?) and similar to Does the C++ standard allow for an uninitialized bool to crash a program?

*(char *)&b = 2;

This type punning hack invoke UB. According to your compiler implementation for bool and the optimization it is allowed to do, you could have demons flying off your nose.

Answer 2

Consider:

bool b;
b = char{2};     // 1
(char&)b = 2;    // 2
*(char*)&b = 2;  // 3

Here, lines 2 and 3 have the same meaning, but 1 has a different meaning. In line 1, since the value being assigned to the bool object is nonzero, the result is guaranteed to be true. However, in lines 2 and 3, the object representation of the bool object is being written to directly.

It is indeed legal to write to an object of any non-const type through an lvalue of type char, but:

In C++17, the standard does not specify the representation of bool objects. The bool type may have padding bits, and may even be larger than char. Thus, any attempt to write directly to a bool value in this way may yield an invalid (or "trap") object representation, which means that subsequently reading that value will yield undefined behaviour. Implementations may (but are not required by the standard to) define the representation of bool objects.

In C++20, my understanding is that thanks to P1236R1, there are no longer any trap representations, but the representation of bool is still not completely specified. The bool object may still be larger than char, so if you write to only the first byte of it, it can still contain an indeterminate value, yielding UB when accessed. If bool is 1 byte (which is likely), then the result is unspecified---it must yield some valid value of the underlying type (which will most likely be char or its signed or unsigned cousin) but the mapping of such values to true and false remains unspecified.

Answer 3

It's OK to assign values other than true and false to a variable of type bool.

The RHS is converted to a bool by using the standard conversion sequence to true/false before the value is assigned.

However, what you are trying to do is not OK.

*(char *)&b = 2;  // Not OK
*(char *)&b = 3;  // Not OK

Even assigning 1 and 0 by using that mechanism is not OK.

*(char *)&b = 1;  // Not OK
*(char *)&b = 0;  // Not OK

The following statements are OK.

b = 2; // OK
b = 3; // OK

Update, in response to OP's comment.

From the standard/basic.types#basic.fundamental-6:

Values of type bool are either true or false.

The standard does not mandate that true be represented as 1 and/or false be represented as 0. An implementation can choose a representation that best suits their needs.

The standard goes on to say this about value of bool types:

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.

Storing the value char(1) or char(0) in its memory location indirectly does not guarantee that the values will be properly converted to true/false. Since theose value may not represent either true or false in an implementation, accessing those values would lead to undefined behavior.

Answer 4

Writing any integer values into a bool through a pointer to a type other than bool is undefined behavior, because those may not match the compiler's representation of the type. And yes, writing something other than 0 or 1 will absolutely break things: compilers often rely on the exact internal representation of boolean true.

But bool b = 3 is fine, and just sets b to true (the rule for converting from integer types to bool is, any nonzero value becomes true and zero becomes false).

Answer 5

In general, it's perfectly find to assign values other than 0 or 1 to a bool:

7.3.14 Boolean conversions [conv.bool] 1 A prvalue of arithmetic, unscoped enumeration, pointer, or pointer-to-member type can be converted to a prvalue of type bool. A zero value, null pointer value, or null member pointer value is converted to false; any other value is converted to true.

But your casting is another question entirely.

Be careful thinking it's ok to write to types through pointers to something else. You can get very surprising results, and the optimizer is allowed to assume certain such things are not done. I don't know all the rules for it, but the optimizer doesn't always follow writes through pointers to different types (it is allowed to do all sorts of things in the presence of undefined behavior!) But beware, code like this:

bool f()
{
    bool a = true;
    bool b = true;
    *reinterpret_cast<char*>(&a) = 1;
    *reinterpret_cast<char*>(&b) = 2;
    return a == b;
}

Live: https://godbolt.org/z/hJnuSi

With optimizations: g++: -> true (but the value is actually 2) clang: -> false

main() {
    std::cout << f() << "\n";  // g++ prints 2!!!
}

Though f() returns a bool, g++ actually prints out 2 in main here. Probably not expected.