Re: Representation of _Bool

Liste des GroupesRevenir à cl c 
Sujet : Re: Representation of _Bool
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.c
Date : 17. Jan 2025, 05:40:16
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20250116192737.759@kylheku.com>
References : 1 2
User-Agent : slrn/pre1.0.4-9 (Linux)
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.

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

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?

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.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Date Sujet#  Auteur
17 Jan 25 * Re: Representation of _Bool15m137
17 Jan 25 +* Re: Representation of _Bool6Kaz Kylheku
17 Jan 25 i+- Re: Representation of _Bool1David Brown
17 Jan 25 i+- Eternal September server retention Was: Representation of _Bool1Michael S
17 Jan 25 i+- Re: Representation of _Bool1James Kuyper
19 Jan 25 i`* Re: Representation of _Bool2m137
19 Jan 25 i `- Re: Representation of _Bool1Keith Thompson
17 Jan 25 +* Re: Representation of _Bool3Tim Rentsch
19 Jan 25 i`* Re: Representation of _Bool2m137
19 Jan 25 i `- Re: Representation of _Bool1Tim Rentsch
17 Jan 25 `* Re: Representation of _Bool5Keith Thompson
18 Jan 25  +- Re: Representation of _Bool1Tim Rentsch
19 Jan 25  `* Re: Representation of _Bool3m137
19 Jan 25   `* Re: Representation of _Bool2Kenny McCormack
21 Jan 25    `- Re: Representation of _Bool1m137

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal