Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: learningcpp1@gmail.com (m137)
Newsgroups: comp.lang.c
Subject: Re: Representation of =?UTF-8?B?X0Jvb2w=?=
Date: Sun, 19 Jan 2025 02:11:37 +0000
Organization: novaBBS
Message-ID: <8478e1844449ec0a5c2b2fc6fc7453a2@www.novabbs.com>
References: <87tums515a.fsf@nosuchdomain.example.com> <42fcea7270de500367eceea7ad5530fd@www.novabbs.com> <864j1x5lp1.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="65656"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="h4I3C/TQeMNW2qYH6OSH32NZuxQQNBy/f089TkslY9o";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$INlW9JgtDCUjzovfx/0L5OiEQTYH11dU39qKVbjWQTiAyI8yOmnMe
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: b7c53bbe3b6333072e2ddc8ab3b4f124948b1834
Bytes: 4652
Lines: 83

On Fri, 17 Jan 2025 18:39:38 +0000, Tim Rentsch wrote:

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

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.

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

The reason I thought they were different was because the definition of
trap representation uses the phrase "need not", which seemed more
permissive than the "does not" in the definition of non-value
representation.

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

--