Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: Representation of _Bool
Date: Fri, 17 Jan 2025 04:40:16 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 65
Message-ID: <20250116192737.759@kylheku.com>
References: <87tums515a.fsf@nosuchdomain.example.com>
 <42fcea7270de500367eceea7ad5530fd@www.novabbs.com>
Injection-Date: Fri, 17 Jan 2025 05:40:17 +0100 (CET)
Injection-Info: dont-email.me; posting-host="38af279a9afab8a5482df06dca49b170";
	logging-data="4114555"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX186hMhBA6sAdxeDEO3GUeelIlfPicYPURw="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:SMe+LYQvnW+2MT4JDDHg22RqAUY=
Bytes: 3757

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