Re: Representation of _Bool

learningcpp1@gmail.com (m137) writes:

Hi Keith,
>
Thank you for posting this.

Normally followup postings include a reference of some sort to the
article being replied to.

I noticed that the newer drafts of C23
(N2912 onwards, I think) have replaced the term "trap representation"
with "non-value representation":
- **Trap representation** was last defined in [N2731
3.19.4(1)](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2912.pdf#page=)
as "an object representation that need not represent a value of the
object type."
- **Non-value representation** is most recently defined in [N3435
3.26(1)](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3435.pdf#page=23)
as "an object representation that does not represent a value of the
object type."
>
The definition of non-value representation rules out object
representations that represent a value of the object type from being
non-value representations.  So it seems to be stricter than the
definition of trap representation, which does not seem to rule out such
object representations from being trap representations.  Is this
interpretation correct?

No.  Except for using a different name, there is no difference
between "trap representation" and "non-value representation".

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
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).

I don't know that either gcc or clang have any trap representations
for _Bool.  Furthermore whether they do could depend on either which
version or what compiler options are being used.

Let's assume 8-bit chars, and also that the width of _Bool is 1
(which is optional before C23 and required in C23).  Here is what
can be said about the 256 states of a _Bool object.

1. All zero bits must be a legal value for 0.

2. There must be at least one combination of bits that is a legal
value for 1 (and since it must be distinct from the all-zero
value for 0, must have at least one bit set to 1).

3. The remaining 254 possible combinations of bit settings can be
any mixture of legal values and trap representations, which are also
known as non-value representations starting in C23.

4. Considering the set of legal value bit settings, there must be at
least one bit position that is 0 in all cases where the value is
0, and is 1 in all cases where the value is 1.

5. Accessing any representation corresponding to a legal value has
well-defined behavior, and yields 0 or 1 depending on the setting of
the bit (or bits) mentioned in #4.

6. Accessing any trap/non-value representation is undefined behavior
and might do anything at all.  It might appear to work.  It might
work in some cases but not others.  It might yield a value that is
neither 0 or 1.  It might abort the program.  It might cause the
computer the program is running on to run a different operating
system (of course this outcome isn't very likely, but as far as the
C standard is concerned it cannot be ruled out).

Does this answer all your questions?