Re: Representation of _Bool

Path	csiph.com!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> (permalink)
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=
Xref	csiph.com comp.lang.c:390077

Show key headers only | View raw

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.

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