Re: Representation of _Bool

On 17/01/2025 05:40, Kaz Kylheku wrote:

On 2025-01-17, m137 <learningcpp1@gmail.com> wrote:

Hi Keith,
>
Thank you for posting this.

 When, where? No attribution; referenced article is expired from this
Eternal September server, which has decently long retentation times.
 

I noticed that the newer drafts of C23
(N2912 onwards, I think) have replaced the term "trap representation"
with "non-value representation":

 That is correct. Probably because "trap representation" insinuates
that such a representation *must* produce a trap, or else the
implementation has no right to specify such a representation.

Yes, I believe that is the reason.  Earlier standards make it clear in the definitions that accessing a "trap representation" does not imply "performing a trap" - but the term is easily misunderstood for those that read parts of the standard without referring back to the definitions.

 Impelmentations are not obliged to produce traps in relation to
non-value representations. Since the behaviors in question are
undefined, they may do so.

Agreed.  I can't see any differences in the semantics here - only the term used has changed.

 

If so, what happens to the 254 trap representations that GCC and Clang
reserve for `_Bool`? Assuming a width of 1, each of those 254 object

 GCC and Clang specifies trap representations for _Bool? Where is this
found in their documentation?
 

I can't answer for clang - I don't know it in high enough detail.  But gcc certainly considers the use of _Bool representations other than 0 or 1 as undefined behaviour (except when accessed through a char type lvalue - such as by memcpy).  I once had a bug where data memcpy'ed into a struct containing a bool resulted in a bool that had something other than 0 or 1 in the memory byte - and that lead to the both "true" and "false" paths being followed in some code that used it.
That was, of course, perfectly good code generation for undefined behaviour.
But to be clear - it was UB, not a trap.  Pre-C23 usage of "trap representations" is UB and may or may not perform a trap, depending on the implementation (including any flags it is given).  With C23, it would now have the more appropriate name "non-value representation" and exactly the same effect.
gcc now has a new "hardbool" feature, implemented as a type attribute:
<https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#index-hardbool-type-attribute>
This lets you create new types that act much like booleans, except that you can specify the true and false representations directly, and that other representations are actually trapping - they are checked at runtime and lead to a call to __builtin_trap().

representations represents a value in `_Bool`'s domain (the half whose
value bit is 1 represents the value `true`, while the other half whose
value bit is 0 represents the value `false`), so they cannot be thought
of as non-value representations (since a non-value representation must
be an object representation that **does not** represent a value of the
object type).

 In an integer type, it is indeed possible for the padding bits to be
nonzero, without changing the value given by the value bits.
 However, how that works is not specified; it's up to an implementation,
and doesn't have to be documented.
 An implementation could say that the padding bits don't mean anything;
they can have any value whatsoever and so the situation is as you
say: the bool representations with a 0 in the value bit are all false,
and those with a 1 are all true.
 However, an implementation can also say that certain patterns of
bits are non-value reprensentations.
 One example given is the possibility of parity bits. Suppose some
integer type has one padding bit which behaves as a parity bit.  Then
suppose whenever that bit has incorrect parity, the representation is
deemed a non-value representation.
 With regard to bool (say, one implemented in 8 bits), an impelmentation
can assert that if there is a nonzero value in any padding bit, the
result is a non-value representation. Then, only 0 and 1 are valid;
all other byte codes are non-value representations.
 Implementations determine their own rules for how configurations of
padding bits may, on their own, or in interaction with configurations
of value bits, give rise to non-value representations.
 

All good stuff, nicely written.