Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #390066

Re: Representation of _Bool

Show all headers | View raw

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?

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Representation of _Bool learningcpp1@gmail.com (m137) - 2025-01-17 02:47 +0000
  Re: Representation of _Bool Kaz Kylheku <643-408-1753@kylheku.com> - 2025-01-17 04:40 +0000
    Re: Representation of _Bool David Brown <david.brown@hesbynett.no> - 2025-01-17 10:18 +0100
    Eternal September server retention Was: Representation of _Bool Michael S <already5chosen@yahoo.com> - 2025-01-17 12:06 +0200
    Re: Representation of _Bool James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-01-17 14:10 -0500
    Re: Representation of _Bool learningcpp1@gmail.com (m137) - 2025-01-19 02:08 +0000
      Re: Representation of _Bool Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-18 18:28 -0800
  Re: Representation of _Bool Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-17 10:39 -0800
    Re: Representation of _Bool learningcpp1@gmail.com (m137) - 2025-01-19 02:11 +0000
      Re: Representation of _Bool Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-18 20:37 -0800
  Re: Representation of _Bool Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-17 13:34 -0800
    Re: Representation of _Bool Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-18 12:17 -0800
    Re: Representation of _Bool learningcpp1@gmail.com (m137) - 2025-01-19 02:30 +0000
      Re: Representation of _Bool gazelle@shell.xmission.com (Kenny McCormack) - 2025-01-19 09:31 +0000
        Re: Representation of _Bool learningcpp1@gmail.com (m137) - 2025-01-21 00:16 +0000

csiph-web