C99 indicates that a _Bool is an unsigned integer type. When a variable of a type other than _Bool is assigned to a _Bool, C99 specifies that the _Bool receives the value of 0 if the variable was 0, or 1 otherwise.

But what does C99 say about a _Bool that is corrupted to a value other than 0 or 1 (perhaps through a pointer error in another part of the program)? Will this corrupted _Bool still function correctly?

For example:

_Bool a = true;
_Bool b; /* Assume b is corrupted to "2" somehow */

if (a && b)
{ /* Would the compiler be able to use a bitwise */
/* AND above, because it assumes all _Bools */
/* must be 0 or 1, so that if (1 && 2) becomes */
/* if (1 & 2) and evaluates false? */
}

Thanks for any clarification.

"das...@gmail.com" <dashley@gmail.com> writes:
> C99 indicates that a _Bool is an unsigned integer type. When a
> variable of a type other than _Bool is assigned to a _Bool, C99
> specifies that the _Bool receives the value of 0 if the variable was
> 0, or 1 otherwise.
>
> But what does C99 say about a _Bool that is corrupted to a value other
> than 0 or 1 (perhaps through a pointer error in another part of the
> program)? Will this corrupted _Bool still function correctly?
>
> For example:
>
> _Bool a = true;
> _Bool b; /* Assume b is corrupted to "2" somehow */
>
> if (a && b)
> {
> /* Would the compiler be able to use a bitwise */
> /* AND above, because it assumes all _Bools */
> /* must be 0 or 1, so that if (1 && 2) becomes */
> /* if (1 & 2) and evaluates false? */
> }
>
> Thanks for any clarification.

I'm reasonably sure that anything that would cause a _Bool object to
have a value other than 0 or 1, or at least anything that tried to
access such an object's value, would have undefined behavior.

Using bitwise AND for the code above is one of the infinitely many
things a compiler could do.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> "das...@gmail.com" <dashley@gmail.com> writes:
>> C99 indicates that a _Bool is an unsigned integer type. When a
>> variable of a type other than _Bool is assigned to a _Bool, C99
>> specifies that the _Bool receives the value of 0 if the variable was
>> 0, or 1 otherwise.
>>
>> But what does C99 say about a _Bool that is corrupted to a value other
>> than 0 or 1 (perhaps through a pointer error in another part of the
>> program)? Will this corrupted _Bool still function correctly?
>>
>> For example:
>>
>> _Bool a = true;
>> _Bool b; /* Assume b is corrupted to "2" somehow */
>>
>> if (a && b)
>> {
>> /* Would the compiler be able to use a bitwise */
>> /* AND above, because it assumes all _Bools */
>> /* must be 0 or 1, so that if (1 && 2) becomes */
>> /* if (1 & 2) and evaluates false? */
>> }
>>
>> Thanks for any clarification.
>
> I'm reasonably sure that anything that would cause a _Bool object to
> have a value other than 0 or 1, or at least anything that tried to
> access such an object's value, would have undefined behavior.
>
> Using bitwise AND for the code above is one of the infinitely many
> things a compiler could do.

And C23 (see the N3096 public draft) clarifies that bool has one value
bit (sizeof(bool)*CHAR_BIT)-1 padding bits. (bool is a keyword in C23;
_Bool and <stdbool.h> are kept for backward compatibility.)

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 7/11/23 21:51, Keith Thompson wrote:
> "das...@gmail.com" <dashley@gmail.com> writes:
>> C99 indicates that a _Bool is an unsigned integer type. When a
>> variable of a type other than _Bool is assigned to a _Bool, C99
>> specifies that the _Bool receives the value of 0 if the variable was
>> 0, or 1 otherwise.
>>
>> But what does C99 say about a _Bool that is corrupted to a value other
>> than 0 or 1 (perhaps through a pointer error in another part of the
>> program)? Will this corrupted _Bool still function correctly?
>>
>> For example:
>>
>> _Bool a = true;
>> _Bool b; /* Assume b is corrupted to "2" somehow */
>>
>> if (a && b)
>> {
>> /* Would the compiler be able to use a bitwise */
>> /* AND above, because it assumes all _Bools */
>> /* must be 0 or 1, so that if (1 && 2) becomes */
>> /* if (1 & 2) and evaluates false? */
>> }
>>
>> Thanks for any clarification.
>
> I'm reasonably sure that anything that would cause a _Bool object to
> have a value other than 0 or 1, or at least anything that tried to
> access such an object's value, would have undefined behavior.

You know this, but the OP might not realize it: one of the (infinitely
many) permitted consequence of the fact that your code has undefined
behavior is that an object with a type of _Bool might, when accessed,
have a result (such as 2) that is not one a valid _Bool value.

On 12/07/2023 02:32, das...@gmail.com wrote:
> C99 indicates that a _Bool is an unsigned integer type. When a
> variable of a type other than _Bool is assigned to a _Bool, C99
> specifies that the _Bool receives the value of 0 if the variable was 0,
> or 1 otherwise.
>
> But what does C99 say about a _Bool that is corrupted to a value
> other
> than 0 or 1 (perhaps through a pointer error in another part of the
> program)? Will this corrupted _Bool still function correctly?
>
> For example:
>
> _Bool a = true;
> _Bool b; /* Assume b is corrupted to "2" somehow */
>
> if (a && b)
> {
> /* Would the compiler be able to use a bitwise */
> /* AND above, because it assumes all _Bools */
> /* must be 0 or 1, so that if (1 && 2) becomes */
> /* if (1 & 2) and evaluates false? */
> }
>
> Thanks for any clarification.

You have absolutely no guarantees - it is all "undefined behaviour". If
you make a _Bool with a value other than 0 or 1 (say, by using memcpy()
or a char* pointer to access it), any attempt to use it will be undefined.

This means the compiler can, and will, assume that any _Bool expression
will be 0 or 1. It can implement the "if (a && b)" expression any way
it likes that is consistent with that assumption. So given _Bool "a"
and "b", the compiler can implement "if (a && b) ..." as :

if (a) {
if (b) ...
}

or

if (b) {
if (a == 0) {} else { ... }
}

or

if (a + b == 2) ...

or

if (a & b) ...

or

if (a * b) ...

or

if (a << 1 | b == 3) ...

There really is no limit to how this could be implemented.

You can also get effects like :

if (a) { doThis(); } else { doThat(); }

resulting in /both/ doThis() and doThat() being executed, or perhaps
neither of them, if "a" is a corrupted _Bool.

(I remember debugging a program where there was an accidental _Bool
corruption, leading to exactly this kind of effect. It was seriously
confusing!)

When you use _Bool, you promise your compiler that you will never break
the languages rules and ask it to handle a _Bool with a value other than
0 or 1. Don't lie to your compiler - it always ends in tears!

On 12/07/2023 02:32, das...@gmail.com wrote:
> C99 indicates that a _Bool is an unsigned integer type. When a variable of a type other than _Bool is assigned to a _Bool, C99 specifies that the _Bool receives the value of 0 if the variable was 0, or 1 otherwise.
>
> But what does C99 say about a _Bool that is corrupted to a value other than 0 or 1 (perhaps through a pointer error in another part of the program)? Will this corrupted _Bool still function correctly?
>

It's undefined behavior. Just like if you corrupt any value of any other
type.

> For example:
>
> _Bool a = true;
> _Bool b; /* Assume b is corrupted to "2" somehow */
>
> if (a && b)
> {
> /* Would the compiler be able to use a bitwise */
> /* AND above, because it assumes all _Bools */
> /* must be 0 or 1, so that if (1 && 2) becomes */
> /* if (1 & 2) and evaluates false? */
> }
>
> Thanks for any clarification.

If the memory holding a _Bool value gets corrupted, there is obviously
no way for the compiler to automatically correct it. How would it?

It's UB, but the practical result will of course depend on the target. A
_Bool is held by an integer under the hood in practice.

Compilers do force a value of 1 for any value other than 0 assigned to
it *during assignment*, and 0 otherwise. But again, only when an
assignment occurs (or a cast).

For instance, the expression '(int)(_Bool) 5' yields 1.

But if you alias a _Bool, say:

_Bool b;

*(int *) &b = 5;

While UB, in practice in most implementations, b will be represented
internally as an int and here will hold the value 5. Not 1.
This would cause a problem if you expect the value to be either 0 or 1
exclusively. For instance if you cast it back to an int and do some
artihmetic or bitwise operations with that.

Regarding what would happen to '(a && b)' in your example, the '&&'
operator is NOT a bitwise operator. Even when dealing strictly with
_Bool's on each side of the operator, it can't be implemented with a
bitwise operation when compiled. Quoting the standard regarding the '&&'
operator:

"The && operator shall yield 1 if both of its operands compare unequal
to 0; otherwise, it yields 0. The result has type int.
Unlike the bitwise binary & operator, the && operator guarantees left
to-right evaluation;
if the second operand is evaluated, there is a sequence point between
the evaluations of the first and second operands. If the first operand
compares equal to 0, the second operand is not evaluated."

That should answer your question.

Opus <ifonly@youknew.org> writes:

> On 12/07/2023 02:32, das...@gmail.com wrote:
>> C99 indicates that a _Bool is an unsigned integer type. When a
>> variable of a type other than _Bool is assigned to a _Bool, C99
>> specifies that the _Bool receives the value of 0 if the variable was
>> 0, or 1 otherwise.
>> But what does C99 say about a _Bool that is corrupted to a value
>> other than 0 or 1 (perhaps through a pointer error in another part
>> of the program)? Will this corrupted _Bool still function
>> correctly?
>>
>
> It's undefined behavior. Just like if you corrupt any value of any
> other type.
>
>> For example:
>> _Bool a = true;
>> _Bool b; /* Assume b is corrupted to "2" somehow */
>> if (a && b)
>> {
>> /* Would the compiler be able to use a bitwise */
>> /* AND above, because it assumes all _Bools */
>> /* must be 0 or 1, so that if (1 && 2) becomes */
>> /* if (1 & 2) and evaluates false? */
>> }
>> Thanks for any clarification.
>
> If the memory holding a _Bool value gets corrupted, there is obviously
> no way for the compiler to automatically correct it. How would it?
>
> It's UB, but the practical result will of course depend on the
> target. A _Bool is held by an integer under the hood in practice.
>
> Compilers do force a value of 1 for any value other than 0 assigned to
> it *during assignment*, and 0 otherwise. But again, only when an
> assignment occurs (or a cast).

More precisely, *conversion* from any scalar type to _Bool yields a
value of 0 if the converted value is 0, 1 otherwise. Assignment
performs an implicit conversion; so do argument passing, initialization,
and a return statement. And of course a cast performs an explicit
conversion.

> For instance, the expression '(int)(_Bool) 5' yields 1.
>
> But if you alias a _Bool, say:
>
> _Bool b;
>
> *(int *) &b = 5;
>
> While UB, in practice in most implementations, b will be represented
> internally as an int and here will hold the value 5. Not 1.

_Bool is most likely smaller than int, so the assignment is likely to
clobber bytes not belonging to the _Bool object.

> This would cause a problem if you expect the value to be either 0 or 1
> exclusively. For instance if you cast it back to an int and do some
> artihmetic or bitwise operations with that.
>
> Regarding what would happen to '(a && b)' in your example, the '&&'
> operator is NOT a bitwise operator. Even when dealing strictly with
> _Bool's on each side of the operator, it can't be implemented with a
> bitwise operation when compiled. Quoting the standard regarding the
> '&&' operator:
>
> "The && operator shall yield 1 if both of its operands compare unequal
> to 0; otherwise, it yields 0. The result has type int.
> Unlike the bitwise binary & operator, the && operator guarantees left
> to-right evaluation;
> if the second operand is evaluated, there is a sequence point between
> the evaluations of the first and second operands. If the first operand
> compares equal to 0, the second operand is not evaluated."

Yes, but if a and b are both of type _Bool, the compiler can assume that
they both have a value of 0 or 1. If that assumption is valid (and if a
and b are not volatile), then `a & b` and `a && b` yield the same value.
If the assumption is not valid, then the behavior of `a && b` is
undefined.

A compiler *can* implement `a && b` as `a & b` if both are of type _Bool
and neither is volatile.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 7/12/23 16:10, Opus wrote:
> On 12/07/2023 02:32, das...@gmail.com wrote:
>> C99 indicates that a _Bool is an unsigned integer type. When a
>> variable of a type other than _Bool is assigned to a _Bool, C99
>> specifies that the _Bool receives the value of 0 if the variable was
>> 0, or 1 otherwise.
>>
>> But what does C99 say about a _Bool that is corrupted to a value
>> other than 0 or 1 (perhaps through a pointer error in another part of
>> the program)? Will this corrupted _Bool still function correctly?
>>
>
> It's undefined behavior. Just like if you corrupt any value of any
> other type.

Not quite. The unsigned size-named types are prohibited from having
padding bits, and have requirements on the different possible values
that they can represent that guarantee that every possible bit pattern
represents a valid value. As a result, placing an arbitrary bit pattern
in an object of one of those types, if done by a method that has in
itself no undefined behavior, has no worse consequence than to leave the
value represented unspecified - it must still be a valid value of that type.

....
> If the memory holding a _Bool value gets corrupted, there is obviously
> no way for the compiler to automatically correct it. How would it?

An implementation could generate code for every access through an lvalue
of type _Bool that is equivalent to retrieving an integer value from
that location and then doing the equivalent of !!val, or val&1, or any
other operation that maps 0 to 0 and 1 to 1, and maps every valid
integer value to one of those two values.

Implementations are not required to do that, which is what makes such
code dangerous. However, they are permitted to that, which is what would
make is possible for the code to be safe with a particular implementation.

On Wednesday, July 12, 2023 at 6:45:06 PM UTC-4, James Kuyper wrote:
> An implementation could generate code for every access through an lvalue
> of type _Bool that is equivalent to retrieving an integer value from
> that location and then doing the equivalent of !!val, or val&1, or any
> other operation that maps 0 to 0 and 1 to 1, and maps every valid
> integer value to one of those two values.
>
> Implementations are not required to do that, which is what makes such
> code dangerous. However, they are permitted to that, which is what would
> make is possible for the code to be safe with a particular implementation..

Thanks for the informative replies. Opus' interpretation comes the closest to how I read the C99 standard,
but James Kuyper's reply comes closest to how I think about the problem (as mapping).

I often see code like this:

typedef unsigned char boolean;
boolean a = FALSE;
boolean b = TRUE;
a = 42; //Oops, some other part of the program used an uninitialized pointer.
if ((a == FALSE) && (b == TRUE)) ...

The problem I have with the tests against FALSE and TRUE is that there are 254 values that are neither FALSE nor TRUE. This is an "equivalence classing" or "mapping" problem. Every possible bit pattern has to behave as if it is FALSE or TRUE.

One solution is this: if (!a && b) ...

Another solution is: if ((a == FALSE) && (b != FALSE)) ...

So, back to my original post ...

SOUGHT GUARANTEE: I'm only looking for one guarantee: for a given improper (corrupted) value of a _Bool on a given platform, it will always test as if it is logically false or logically true. In other words, the compiler can't use methods that would result in a value of 42 testing as false in one place and true in another. This is ultimately a mapping or equivalence-classing requirement. All bit patterns would have to map to false or true.

Do I have this guarantee?

And the followup question would be, in the event of corruption, what happens if you do any of these things?

if (a == b) ...
if (a == false) ...
if (a == true) ...

"das...@gmail.com" <dashley@gmail.com> writes:

> On Wednesday, July 12, 2023 at 6:45:06 PM UTC-4, James Kuyper wrote:
>> An implementation could generate code for every access through an lvalue
>> of type _Bool that is equivalent to retrieving an integer value from
>> that location and then doing the equivalent of !!val, or val&1, or any
>> other operation that maps 0 to 0 and 1 to 1, and maps every valid
>> integer value to one of those two values.
>>
>> Implementations are not required to do that, which is what makes such
>> code dangerous. However, they are permitted to that, which is what would
>> make is possible for the code to be safe with a particular implementation.
>
> Thanks for the informative replies. Opus' interpretation comes the
> closest to how I read the C99 standard, but James Kuyper's reply comes
> closest to how I think about the problem (as mapping).
>
> I often see code like this:
>
> typedef unsigned char boolean;
> boolean a = FALSE;
> boolean b = TRUE;
> a = 42; //Oops, some other part of the program used an uninitialized pointer.
> if ((a == FALSE) && (b == TRUE)) ...
>
> The problem I have with the tests against FALSE and TRUE is that there
> are 254 values that are neither FALSE nor TRUE. This is an
> "equivalence classing" or "mapping" problem. Every possible bit
> pattern has to behave as if it is FALSE or TRUE.
>
> One solution is this: if (!a && b) ...

Yes. This is how you were supposed to do it before _Bool came along.
Is it not possible to correct the code? Seeing x == TRUE is a huge
red-flag for me. I'd want it fixed as soon as possible.

> Another solution is: if ((a == FALSE) && (b != FALSE)) ...
>
> So, back to my original post ...
>
> SOUGHT GUARANTEE: I'm only looking for one guarantee: for a given
> improper (corrupted) value of a _Bool on a given platform, it will
> always test as if it is logically false or logically true.

The language does not give you this guarantee. Any access to a
"corrupt" _Bool object is undefined. The language gives an
implementation permission to do what it likes in such cases.

Of course, an implementation of C could choose to fix exactly what
happens in these cases, but then you are relying on a promise that might
be withdrawn at the next release.

> In other words, the compiler can't use methods that would result in a
> value of 42 testing as false in one place and true in another. This
> is ultimately a mapping or equivalence-classing requirement. All bit
> patterns would have to map to false or true.
>
> Do I have this guarantee?

Ironically you do have this guarantee for typedef unsigned char boolean
objects -- provided the accesses are in the right sort of context --
because there are no padding bits in unsigned char objects. For

unsigned char a, b;

code like

if (a && !b) ...

is always well-defined and "Boolean-like". For example a || b is always
0 or 1.

So switching to _Bool gives you more problem. The very access is
undefined.

Mind you, going "up a level" in your issues, unless the corruption
occurs in a very specific way, the program's behaviour is already
undefined even when using unsigned char.

> And the followup question would be, in the event of corruption, what
> happens if you do any of these things?
>
> if (a == b) ...
> if (a == false) ...
> if (a == true) ...

All formally undefined if a or b is a _Bool object. All formally
defined (though maybe not meaning what was intended) if a and b are
unsigned char.

You can get some help from some compilers. For example:

$ cat b.c
#include <stdio.h>

int main(void)
{ union { _Bool b; char c; } both;
both.c = 42;
printf("%d\n", both.b);
} $ gcc -o b -fsanitize=undefined b.c
$ ./b
b.c:7:25: runtime error: load of value 42, which is not a valid value
for type '_Bool'
0

--
Ben.

"das...@gmail.com" <dashley@gmail.com> writes:
> On Wednesday, July 12, 2023 at 6:45:06 PM UTC-4, James Kuyper wrote:
>> An implementation could generate code for every access through an lvalue
>> of type _Bool that is equivalent to retrieving an integer value from
>> that location and then doing the equivalent of !!val, or val&1, or any
>> other operation that maps 0 to 0 and 1 to 1, and maps every valid
>> integer value to one of those two values.
>>
>> Implementations are not required to do that, which is what makes such
>> code dangerous. However, they are permitted to that, which is what would
>> make is possible for the code to be safe with a particular implementation.
>
> Thanks for the informative replies. Opus' interpretation comes the
> closest to how I read the C99 standard, but James Kuyper's reply comes
> closest to how I think about the problem (as mapping).
>
> I often see code like this:
>
> typedef unsigned char boolean;
> boolean a = FALSE;
> boolean b = TRUE;
> a = 42; //Oops, some other part of the program used an uninitialized pointer.
> if ((a == FALSE) && (b == TRUE)) ...
>
> The problem I have with the tests against FALSE and TRUE is that there
> are 254 values that are neither FALSE nor TRUE. This is an
> "equivalence classing" or "mapping" problem. Every possible bit
> pattern has to behave as if it is FALSE or TRUE.

Presumably FALSE and TRUE are #defined as 0 and 1, respectively.

This "boolean" type is not _Bool. It has (typically) 8 value bits and
256 distinct values, all equally valid.

Like any scalar type, if you use a value of this type as a condition,
it's treated as false if it compares equal to 0, true otherise.

It's common in pre-1999 C to use some integer type (char, unsigned
char, int) as a logically boolean type. You have to be aware that
the compiler doesn't assign any meaning to the fact that you named it
"boolean".

I use _Bool if at all possible, but if I can't assume it's available, I
like:

typedef enum { false, true } bool;

But again, an object of this enumerated type has at least 256 distinct
values, and I need to avoid assigning values other than false or true.

One option is to carefully write your code so that no value other than 0
or 1 is ever stored in an object of your pseudo-boolean type -- but
that's very ndifficult to do consistently, and the compiler will not
warn you if you make a mistake.

A better option is to avoid using any operations that care which
non-zero value an object of your type has. *Never* compiler a logically
boolean value for equality or inequality to FALSE or TRUE. Don't write
`if (a == FALSE && b == TRUE)`; write `if (!a && b)`.

> One solution is this: if (!a && b) ...
>
> Another solution is: if ((a == FALSE) && (b != FALSE)) ...

It happens that comparison to FALSE is safer than comparison to TRUE,
but the comparison is unnecessary clutter.

> So, back to my original post ...
>
> SOUGHT GUARANTEE: I'm only looking for one guarantee: for a given
> improper (corrupted) value of a _Bool on a given platform, it will
> always test as if it is logically false or logically true. In other
> words, the compiler can't use methods that would result in a value of
> 42 testing as false in one place and true in another. This is
> ultimately a mapping or equivalence-classing requirement. All bit
> patterns would have to map to false or true.
>
> Do I have this guarantee?

No, you absolutely do not have this guarantee. If you've managed to
store a value other than 0 or 1 in a _Bool object, any use of that value
has undefined behavior. Just don't.

> And the followup question would be, in the event of corruption, what
> happens if you do any of these things?
>
> if (a == b) ...
> if (a == false) ...
> if (a == true) ...

Undefined behavior -- and at least for the 2nd and 3rd lines, rejection
in a code review.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 13/07/2023 01:41, das...@gmail.com wrote:
> On Wednesday, July 12, 2023 at 6:45:06 PM UTC-4, James Kuyper wrote:
>> An implementation could generate code for every access through an lvalue
>> of type _Bool that is equivalent to retrieving an integer value from
>> that location and then doing the equivalent of !!val, or val&1, or any
>> other operation that maps 0 to 0 and 1 to 1, and maps every valid
>> integer value to one of those two values.
>>
>> Implementations are not required to do that, which is what makes such
>> code dangerous. However, they are permitted to that, which is what would
>> make is possible for the code to be safe with a particular implementation.
>
> Thanks for the informative replies. Opus' interpretation comes the closest to how I read the C99 standard,
> but James Kuyper's reply comes closest to how I think about the problem (as mapping).
>

Opus' interpretation was not quite accurate.

The standard does not say anything about the size of _Bool. C23, IIRC,
says it has 1 value bit and the rest of the bits are padding, and its
size must be a multiple of unsigned char. Every implementation I have
seen has sizeof(_Bool) equal to 1 - it is held in a single byte, while
"int" in most implementations (except for some DSPs or other niche
devices) will be multiple bytes.

So while a _Bool is a standard unsigned integer type - it is /not/ an
"int" (or "unsigned int" for that matter).

As others have said, it is better to say that any conversion (allowed by
the language) to _Bool results in a value of 0 or 1, rather than
specifically referring to assignment. The conversion is done exactly as
though you had compared the original value "x" to 0 - if the comparison
is true, the result is 0, otherwise it is 1. It is also equivalent to
writing "!!x", which will result in an int with value 0 or 1.

Opus is also inaccurate about the implementation of &&. It is correct
(and important) to note that in the expression "A && B", "B" is not
evaluated unless "A" compares unequal to 0. But implementations are
free to generate code in all kinds of ways as long as the observable
behaviour of the program is correct. So if evaluating B does not have
any side effects (such as volatile accesses, as Keith mentioned),
implementations can (and do) assume that _Bool "A" and "B" are either 0
or 1, and use bitwise & to implement the logical &&.

> I often see code like this:
>
> typedef unsigned char boolean;

That was common in pre-C99 code. It was also common to use "int" for
such typedefs. Typically there is also:

#define FALSE 0
#define TRUE 1

Sometimes "typedef enum { FALSE, TRUE } boolean;" is used instead.

And occasionally you see horrors such as:

#define TRUE -1
#define FALSE 0

or :

#define TRUE (1 == 1)
#define FALSE (!TRUE)

These are indications that the programmer who wrote them has very little
understanding of the language, and you should treat all the code with
caution and scepticism.

These should never be found in C99 or newer code, except possibly for
interacting with old code.

> boolean a = FALSE;
> boolean b = TRUE;
> a = 42; //Oops, some other part of the program used an uninitialized pointer.
> if ((a == FALSE) && (b == TRUE)) ...
>

Any comparison to FALSE and TRUE like this (or with C99 _Bool,
comparison to false or true) is an indicator that the programmer is not
competent or confident in the language. There /may/ be good reasons for
writing it, but it is usually a warning sign. The evaluation of the
operands to logical &&, and to "if", already contain implicit
comparisons to 0.

Prefer "if (!a && b)". This will be correct for all proper use of
boolean types, including sane pre-C99 definitions. (For the insane
definitions, the code is already a disaster.)

> The problem I have with the tests against FALSE and TRUE is that there are 254 values that are neither FALSE nor TRUE. This is an "equivalence classing" or "mapping" problem. Every possible bit pattern has to behave as if it is FALSE or TRUE.
>

Conversion to _Bool, and conversion to "logical" values (for "if",
"while", &&, ?:, and several other contexts in C) are always done by
comparison to 0. Anything that compares equal to 0, results in 0 (as a
_Bool or an int, depending on context), everything else results in 1.

> One solution is this: if (!a && b) ...

Yes.

>
> Another solution is: if ((a == FALSE) && (b != FALSE)) ...

No. Well, it gives the same result, unlike "b == TRUE" (if "b" is a
"fake boolean rather than a C99 _Bool). But again, it is pointless
redundancy that indicates a limited understanding of the language.

Note that /any/ scaler type can be compared to 0 - that includes
pointers as well as other integer types and floating point types. For
pointers, "if (!a && b)" then reads as "If a is a null pointer and b is
not a null pointer", while "if ((a == FALSE) && (b != FALSE))" reads as
"I am confused and am mixing pointers and booleans".

>
> So, back to my original post ...
>
> SOUGHT GUARANTEE: I'm only looking for one guarantee: for a given improper (corrupted) value of a _Bool on a given platform, it will always test as if it is logically false or logically true. In other words, the compiler can't use methods that would result in a value of 42 testing as false in one place and true in another. This is ultimately a mapping or equivalence-classing requirement. All bit patterns would have to map to false or true.
>
> Do I have this guarantee?

Not with a _Bool, no.

You can read the value via a character type (such as a pointer to
unsigned char), and assign it to a _Bool. Then you get the guarantee.

extern _Bool corrupted_bool;

_Bool b = *(unsigned char*) &corrupted_bool;

But simply writing:

_Bool b = corrupted_bool;

will /not/ give you the guarantee. You can't even write:

_Bool b = !!corrupted_bool;

or

_Bool b = (corrupted_bool == 0) ? 0 : 1;

because the compiler can (and probably will) assume that
"corrupted_bool", being type _Bool, always contains 0 or 1.

>
> And the followup question would be, in the event of corruption, what happens if you do any of these things?
>
> if (a == b) ...
> if (a == false) ...
> if (a == true) ...

Demons may come flying out of your nose. But maybe not - there are no
guarantees when you have undefined behaviour!

David Brown <david.brown@hesbynett.no> writes:
[...]
> Sometimes "typedef enum { FALSE, TRUE } boolean;" is used instead.

enum Bool { True, False, FileNotFound };

(Source: https://thedailywtf.com/articles/what_is_truth_0x3f_)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 14/07/2023 00:18, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> Sometimes "typedef enum { FALSE, TRUE } boolean;" is used instead.
>
> enum Bool { True, False, FileNotFound };
>
> (Source: https://thedailywtf.com/articles/what_is_truth_0x3f_)
>

Very nice :-)

Whenever I am pulling out my hair trying to comprehend someone's bad
code, I visit a random page on that site. Then I know the code I am
working on is not as bad as it /could/ be!

On 7/13/2023 3:18 PM, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> Sometimes "typedef enum { FALSE, TRUE } boolean;" is used instead.
>
> enum Bool { True, False, FileNotFound };
>
> (Source: https://thedailywtf.com/articles/what_is_truth_0x3f_)
>

WOW! Good one. :^D

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> "das...@gmail.com" <dashley@gmail.com> writes:
>
>> C99 indicates that a _Bool is an unsigned integer type. When a
>> variable of a type other than _Bool is assigned to a _Bool, C99
>> specifies that the _Bool receives the value of 0 if the variable was
>> 0, or 1 otherwise.
>>
>> But what does C99 say about a _Bool that is corrupted to a value other
>> than 0 or 1 (perhaps through a pointer error in another part of the
>> program)? Will this corrupted _Bool still function correctly?
>>
>> For example:
>>
>> _Bool a = true;
>> _Bool b; /* Assume b is corrupted to "2" somehow */
>>
>> if (a && b)
>> {
>> /* Would the compiler be able to use a bitwise */
>> /* AND above, because it assumes all _Bools */
>> /* must be 0 or 1, so that if (1 && 2) becomes */
>> /* if (1 & 2) and evaluates false? */
>> }
>>
>> Thanks for any clarification.
>
> I'm reasonably sure that anything that would cause a _Bool object
> to have a value other than 0 or 1, or at least anything that tried
> to access such an object's value, would have undefined behavior.

In C99 and also in C11, an implementation may define the type _Bool
to have a size of 1, a width of CHAR_BIT, and a representation that
matches the representation of unsigned char. I'm not aware of any
implementation that makes these choices, but they are allowed under
the rules of the respective ISO C standards (assuming I didn't miss
something, but I'm reasonably sure that I didn't).

Code running in such an implementation can easily store an object
representation, into a _Bool object, of an unsigned char with the
value 2. Because the representations of _Bool and unsigned char
are the same, that is also the object representation of the value 2
considered as a _Bool object.

After the store, reading the _Bool object (as a _Bool) is well
defined, and must produce the value 2, because of how object
representations are turned into values. So, in such an
implementation, 'a && b' might not be the same as 'a & b',
even though no undefined behavior has occurred.

Opus <ifonly@youknew.org> writes:

> On 12/07/2023 02:32, das...@gmail.com wrote:
>
>> C99 indicates that a _Bool is an unsigned integer type. When a
>> variable of a type other than _Bool is assigned to a _Bool, C99
>> specifies that the _Bool receives the value of 0 if the variable was
>> 0, or 1 otherwise.
>>
>> But what does C99 say about a _Bool that is corrupted to a value
>> other than 0 or 1 (perhaps through a pointer error in another part of
>> the program)? Will this corrupted _Bool still function correctly?
>
> It's undefined behavior. Just like if you corrupt any value of any
> other type.

More accurately, it might be undefined behavior but doesn't
have to be, depending on what choices have been made by
the implementation. More details in my previous response
to Keith Thompson's earlier posting.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Opus <ifonly@youknew.org> writes:
>
>> On 12/07/2023 02:32, das...@gmail.com wrote:
>>
>>> C99 indicates that a _Bool is an unsigned integer type. When a
>>> variable of a type other than _Bool is assigned to a _Bool, C99
>>> specifies that the _Bool receives the value of 0 if the variable was
>>> 0, or 1 otherwise.
>>> But what does C99 say about a _Bool that is corrupted to a value
>>> other than 0 or 1 (perhaps through a pointer error in another part
>>> of the program)? Will this corrupted _Bool still function
>>> correctly?
>>
>> It's undefined behavior. Just like if you corrupt any value of any
>> other type.
>>
>>> For example:
>>> _Bool a = true;
>>> _Bool b; /* Assume b is corrupted to "2" somehow */
>>> if (a && b)
>>> {
>>> /* Would the compiler be able to use a bitwise */
>>> /* AND above, because it assumes all _Bools */
>>> /* must be 0 or 1, so that if (1 && 2) becomes */
>>> /* if (1 & 2) and evaluates false? */
>>> }
>>> Thanks for any clarification.
>>
>> If the memory holding a _Bool value gets corrupted, there is obviously
>> no way for the compiler to automatically correct it. How would it?
>>
>> It's UB, but the practical result will of course depend on the
>> target. A _Bool is held by an integer under the hood in practice.
>>
>> Compilers do force a value of 1 for any value other than 0 assigned to
>> it *during assignment*, and 0 otherwise. But again, only when an
>> assignment occurs (or a cast).
>
> More precisely, *conversion* from any scalar type to _Bool yields a
> value of 0 if the converted value is 0, 1 otherwise. Assignment
> performs an implicit conversion; so do argument passing, initialization,
> and a return statement. And of course a cast performs an explicit
> conversion.
>
>> For instance, the expression '(int)(_Bool) 5' yields 1.
>>
>> But if you alias a _Bool, say:
>>
>> _Bool b;
>>
>> *(int *) &b = 5;
>>
>> While UB, in practice in most implementations, b will be represented
>> internally as an int and here will hold the value 5. Not 1.
>
> _Bool is most likely smaller than int, so the assignment is likely to
> clobber bytes not belonging to the _Bool object.
>
>> This would cause a problem if you expect the value to be either 0 or 1
>> exclusively. For instance if you cast it back to an int and do some
>> artihmetic or bitwise operations with that.
>>
>> Regarding what would happen to '(a && b)' in your example, the '&&'
>> operator is NOT a bitwise operator. Even when dealing strictly with
>> _Bool's on each side of the operator, it can't be implemented with a
>> bitwise operation when compiled. Quoting the standard regarding the
>> '&&' operator:
>>
>> "The && operator shall yield 1 if both of its operands compare unequal
>> to 0; otherwise, it yields 0. The result has type int.
>> Unlike the bitwise binary & operator, the && operator guarantees left
>> to-right evaluation;
>> if the second operand is evaluated, there is a sequence point between
>> the evaluations of the first and second operands. If the first operand
>> compares equal to 0, the second operand is not evaluated."
>
> Yes, but if a and b are both of type _Bool, the compiler can
> assume that they both have a value of 0 or 1. [...]

Whether a compiler can safely make such an assumption depends on
implementation choices pertaining to how _Bool objects are
represented.

> A compiler *can* implement `a && b` as `a & b` if both are of type
> _Bool and neither is volatile.

Again, such a conclusion might or might not be valid, depending on
other aspects of the implementation.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> "das...@gmail.com" <dashley@gmail.com> writes:
>>> C99 indicates that a _Bool is an unsigned integer type. When a
>>> variable of a type other than _Bool is assigned to a _Bool, C99
>>> specifies that the _Bool receives the value of 0 if the variable was
>>> 0, or 1 otherwise.
>>>
>>> But what does C99 say about a _Bool that is corrupted to a value other
>>> than 0 or 1 (perhaps through a pointer error in another part of the
>>> program)? Will this corrupted _Bool still function correctly?
>>>
>>> For example:
>>>
>>> _Bool a = true;
>>> _Bool b; /* Assume b is corrupted to "2" somehow */
>>>
>>> if (a && b)
>>> {
>>> /* Would the compiler be able to use a bitwise */
>>> /* AND above, because it assumes all _Bools */
>>> /* must be 0 or 1, so that if (1 && 2) becomes */
>>> /* if (1 & 2) and evaluates false? */
>>> }
>>>
>>> Thanks for any clarification.
>>
>> I'm reasonably sure that anything that would cause a _Bool object
>> to have a value other than 0 or 1, or at least anything that tried
>> to access such an object's value, would have undefined behavior.
>
> In C99 and also in C11, an implementation may define the type _Bool
> to have a size of 1, a width of CHAR_BIT, and a representation that
> matches the representation of unsigned char. I'm not aware of any
> implementation that makes these choices, but they are allowed under
> the rules of the respective ISO C standards (assuming I didn't miss
> something, but I'm reasonably sure that I didn't).

As far as I can tell, gcc's behavior is consistent with that.

> Code running in such an implementation can easily store an object
> representation, into a _Bool object, of an unsigned char with the
> value 2. Because the representations of _Bool and unsigned char
> are the same, that is also the object representation of the value 2
> considered as a _Bool object.
>
> After the store, reading the _Bool object (as a _Bool) is well
> defined, and must produce the value 2, because of how object
> representations are turned into values. So, in such an
> implementation, 'a && b' might not be the same as 'a & b',
> even though no undefined behavior has occurred.

C23 (as of the N3096 draft) resolves this by saying that:

The type bool shall have one value bit and (sizeof(bool)*CHAR_BIT)-1
padding bits.

which means that if sizeof (bool) == 1 and a bool object's
representation is all-bits-one, the value of that bool object is 1
(true), since the (typically 7) padding bits do not contribute to the
value.

This program:

#include <stdio.h>
#include <string.h>
int main(void) {
unsigned char c = -1;
_Bool b;
memcpy(&b, &c, 1);
printf("sizeof b = %zu, b = %d\n", sizeof b, b);
}

produces this output with gcc:

sizeof b = 1, b = 255

C23 doesn't seem to specify whether the resulting representation of b is
a non-value representation (previously "trap representation") or not.
If a representation with any padding bits set to 1 is a non-value
representation, then I *think* that the code has undefined behavior.
(I'm assuming that compilers aren't expected to go to extra effort when
converting *from* bool.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> "das...@gmail.com" <dashley@gmail.com> writes:
>>>
>>>> C99 indicates that a _Bool is an unsigned integer type. When a
>>>> variable of a type other than _Bool is assigned to a _Bool, C99
>>>> specifies that the _Bool receives the value of 0 if the variable was
>>>> 0, or 1 otherwise.
>>>>
>>>> But what does C99 say about a _Bool that is corrupted to a value other
>>>> than 0 or 1 (perhaps through a pointer error in another part of the
>>>> program)? Will this corrupted _Bool still function correctly?
>>>>
>>>> For example:
>>>>
>>>> _Bool a = true;
>>>> _Bool b; /* Assume b is corrupted to "2" somehow */
>>>>
>>>> if (a && b)
>>>> {
>>>> /* Would the compiler be able to use a bitwise */
>>>> /* AND above, because it assumes all _Bools */
>>>> /* must be 0 or 1, so that if (1 && 2) becomes */
>>>> /* if (1 & 2) and evaluates false? */
>>>> }
>>>>
>>>> Thanks for any clarification.
>>>
>>> I'm reasonably sure that anything that would cause a _Bool object
>>> to have a value other than 0 or 1, or at least anything that tried
>>> to access such an object's value, would have undefined behavior.
>>
>> In C99 and also in C11, an implementation may define the type _Bool
>> to have a size of 1, a width of CHAR_BIT, and a representation that
>> matches the representation of unsigned char. I'm not aware of any
>> implementation that makes these choices, but they are allowed under
>> the rules of the respective ISO C standards (assuming I didn't miss
>> something, but I'm reasonably sure that I didn't).
>
> As far as I can tell, gcc's behavior is consistent with that.

I expect that in fact gcc does not make this set of choices. A
way of testing that is to compile this struct definition

struct test_bool_width {
_Bool b : 8; /* or probably any number > 1 */
};

and see if gcc accepts it. On my test system, gcc gives an
error for any width greater than 1.

>> Code running in such an implementation can easily store an object
>> representation, into a _Bool object, of an unsigned char with the
>> value 2. Because the representations of _Bool and unsigned char
>> are the same, that is also the object representation of the value 2
>> considered as a _Bool object.
>>
>> After the store, reading the _Bool object (as a _Bool) is well
>> defined, and must produce the value 2, because of how object
>> representations are turned into values. So, in such an
>> implementation, 'a && b' might not be the same as 'a & b',
>> even though no undefined behavior has occurred.
>
> C23 (as of the N3096 draft) resolves this by saying that:
>
> The type bool shall have one value bit and (sizeof(bool)*CHAR_BIT)-1
> padding bits.
>
> which means that if sizeof (bool) == 1 and a bool object's
> representation is all-bits-one, the value of that bool object is 1
> (true), since the (typically 7) padding bits do not contribute to the
> value.
>
> This program:
>
> #include <stdio.h>
> #include <string.h>
> int main(void) {
> unsigned char c = -1;
> _Bool b;
> memcpy(&b, &c, 1);
> printf("sizeof b = %zu, b = %d\n", sizeof b, b);
> }
>
> produces this output with gcc:
>
> sizeof b = 1, b = 255

Under C23 rules, this program must have had undefined behavior.
The reason is, if there were no undefined behavior, the _Bool
value of b must be either 0 or 1; it cannot be anything else.
Ergo the padding bit values must have produced a non-value
representation, which accounts for the impossible value 255.

> C23 doesn't seem to specify whether the resulting representation of b is
> a non-value representation (previously "trap representation") or not.
> If a representation with any padding bits set to 1 is a non-value
> representation, then I *think* that the code has undefined behavior.
> (I'm assuming that compilers aren't expected to go to extra effort when
> converting *from* bool.)

The non-zero padding bits /can/ produce a non-value representation,
but they aren't required to. Since the program produced an
impossible value, we know that there must have been undefined
behavior, and thus the non-zero padding bits must have resulted
in a non-value representation (since everything else is well
defined).

Note again that this conclusion is based on the C23 rules. In
earlier versions of C this output is possible (as defined behavior)
if CHAR_BIT == 8 and the width of _Bool is also 8; if the width of
_Bool is anything other than 8 then there must have been undefined
behavior (and as before the width of _Bool can be checked using
the struct bit-field definition method).

Disclaimer: I'm pretty sure all the above is right, but I didn't
re-check my statements as carefully as is my usual practice.