Re: Representation of _Bool

On Fri, 17 Jan 2025 18:39:38 +0000, Tim Rentsch wrote:

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

Hi Tim,
Sorry for the confusion, I am new to platform and hadn't realised that I
need to quote Keith's post in my reply.

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

The reason I thought they were different was because the definition of
trap representation uses the phrase "need not", which seemed more
permissive than the "does not" in the definition of non-value
representation.

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?

Yes, thank you for taking the time to reply, I really appreciate it.
Just to clarify, since padding bits do not count towards the value being
represented, in point (2) above, it would have to be the value bit
specifically that is set to 1; and similarly in point (4), the bit
position that is being referred to is the value bit. Is this correct?
--