Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Representation of _Bool
Date: Sat, 18 Jan 2025 20:37:25 -0800
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <86bjw34dx6.fsf@linuxsc.com>
References: <87tums515a.fsf@nosuchdomain.example.com> <42fcea7270de500367eceea7ad5530fd@www.novabbs.com> <864j1x5lp1.fsf@linuxsc.com> <8478e1844449ec0a5c2b2fc6fc7453a2@www.novabbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sun, 19 Jan 2025 05:37:26 +0100 (CET)
Injection-Info: dont-email.me; posting-host="5960255825c9d0bdcad81225e93c7e92";
	logging-data="1578934"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18JY185sXmuROpdE+8qfP4Q94SSH+csqPo="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:7gXWOkHA/Q6/IzQFiMuwKiHAMG4=
	sha1:kDnsGnI7PNrPkHtql8U9tyABjyw=
Bytes: 3987

learningcpp1@gmail.com (m137) writes:

> On Fri, 17 Jan 2025 18:39:38 +0000, Tim Rentsch wrote:
[...]

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

No worries.  Glad you are up to speed now.

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

Yes, I think that's right, but we can't always tell which bit is the
value bit just by looking at the set of legal values.  Consider an
implementation where _Bool 0 is represented by all zeros and _Bool 1
is represented by all ones, and every combination that includes both
zeros and ones (which is everything else) is a trap representation.
The width of _Bool must be 1, but which bit is the value bit?  We
can't tell.  Fortunately the C standard says how different types are
encoded is implementation defined (if not defined explicitly), so we
can consult the documentation to see which bit of _Bool is the value
bit.