Changing a bool to a value other than 0 or 1?

Question

I have the following code:

#include <stdio.h>

int main()
{
    bool b;

    // Set b to 123
    char *p = (char*)&b;
    *p = 123;

    // Check if b is considered to be true
    if (b == true) printf("b is true");

    return 0;
}

b is not considered to be true, so what does true means exactly, is true equals to 1?

Edit: Forgot to say that I'm using Visual C++.

EDIT: I believe what I said was misleading-- I think @KeithThompson is far more correct than I. — druckermanly, Jan 29 '15 at 06:00
@DrewDormann: `char*` is an exception to the strict aliasing rule. Of course, the OP is getting lucky here as `bool` is actually an int in all implementations I've seen. — Ed S., Jan 29 '15 at 06:11
@DrewDormann: No problem. C keeps even veterans entertained at times. I still refer to this once in a while: http://stackoverflow.com/questions/98650/what-is-the-strict-aliasing-rule — Ed S., Jan 29 '15 at 06:17
Do note that a `bool` can be any size, depending on the compiler and platform. It's not necessarily one byte. — Cheers and hth. - Alf, Jan 29 '15 at 15:06

Tony Delroy · Accepted Answer · 2015-01-29T07:25:27.730

bool b;

// Set b to 123
char *p = (char*)&b;
*p = 123;

The C++ Standard leaves it unspecified how bool are stored... e.g. entirely legal for one compiler to use one byte and another to use four. Further, one compiler might store say 0 for false and all-bits-on for true and another 0 and 1 or whatever other values. All that mattered is that when used in a boolean context the logic works correctly, and that when converted to or from an int:

int(b) is 1 if b is true, and 0 if b is false, and
bool(n) is true if-and-only-if n was not 0.

Because of this, the character at the lowest memory address in the bool representation may or may not be consulted when testing the value of the boolean: it could be one compiler's generated code uses a four-byte int that is read then has only the least significant bit or byte tested, which - depending on endianness - may not have been touched by the *p = 123. Similarly, the compiler might read the value into a signed integer register and test for negativeness (expecting an all-bits-on value when true), which could also fail even if *p = 123 had written to the only or most significant byte.

Consequently - even if there was nothing else at play - the line below might not report "b is true"...

// Check if b is considered to be true
if (b == true) printf("b is true");

...but that test is further flawed by...

possibly reading from other bytes in the bool representation that haven't been initialised (uninitialised memory reads have undefined behaviour)
fiddling with the bool value alone inherently has "undefined behaviour"; in terms of "binary writing" to the bool's memory, only a full byte-for-byte copy from another properly initialised bool is guaranteed to leave this bool is a usable state.

@EdS. yikes - my mistake - memory playing tricks. It's the new enum features that default to `int` and allow explicit sizing. Corrected the answer above. Cheers. — Tony Delroy, Jan 29 '15 at 06:38
Well that makes sense; I couldn't find it in the spec :) Still, +1 — Ed S., Jan 29 '15 at 06:39

Michael Burr · Answer 2 · 2015-01-29T07:32:02.923

C++11 says (3.9 "Types" [basic.types]):

The value representation of an object is the set of bits that hold the value of type T. For trivially copyable types, the value representation is a set of bits in the object representation that determines a value, which is one discrete element of an implementation-defined set of values

And (3.9.1 "Fundamental types" [basic.fundamental]):

For character types, all bits of the object representation participate in the value representation. For unsigned character types, all possible bit patterns of the value representation represent numbers. These requirements do not hold for other types.

...

Values of type bool are either true or false

And finally, 5 "Expressions" [expr] says:

If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined.

What is happening is that when you write the value 123 to the memory that the bool object occupies (through the char* p), you're writing something that can't be represented in the bool object's 'value representation'. So when you subsequently access that object through the lvalue b the program exhibits undefined behavior and you have a bool object that is neither true nor false.

And to answer your question about what the value of true is: the standard never actually specifies. It does specify that the true is one of the two values a bool type can represent (the other being false of course). The standard also specifies that true readily converts to 1 and vice versa, 1 readily converts to true. These conversion happen so naturally and easily that I think that nearly everyone considers true to have the value 1.

One thing to remember is that nearly any non-zero integral value will readily convert to true - not just 1. However that doesn't happen in your example for the value 123 because in that expression it is being written to an lvalue with char type so no conversion to bool occurs.

I don't think that quote from [expr] covers this case; it's talking about things like integer overflow — M.M, Apr 13 '17 at 09:45

score 0 · Answer 3 · answered Jan 29 '15 at 06:02

0

true means 1

But 123 is also considered as true (Generally all integers except zero)

if you say

if (b) printf("b is true");

you must get the output b is true

answered Jan 29 '15 at 06:02

dsharew

10,377
6
49
75

accepted!, I myself usually use positive ints for true. Thanks – dsharew Jan 29 '15 at 06:05

Changing a bool to a value other than 0 or 1?

3 Answers3

Linked