Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: how cast works?
Date: Sun, 11 Aug 2024 20:14:01 -0700
Organization: None to speak of
Lines: 71
Message-ID: <87plqee8li.fsf@nosuchdomain.example.com>
References: <v8vlo9$2oc1v$1@dont-email.me> <slrnvb7kis.28a.dan@djph.net>
	<v929ah$3u7l7$1@dont-email.me> <v92gt1$e1l$1@dont-email.me>
	<20240808193203.00006287@yahoo.com> <v92va5$4msg$1@dont-email.me>
	<v9310a$4v1a$2@dont-email.me> <v93565$6ffo$1@dont-email.me>
	<v93h12$9vom$1@dont-email.me>
	<87frre8v5q.fsf@nosuchdomain.example.com>
	<v95fcj$pv2g$1@dont-email.me>
	<87ttft7bei.fsf@nosuchdomain.example.com> <86frrak3hf.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Mon, 12 Aug 2024 05:14:02 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="95de69de4fa23f7b87735178c0e02b79";
	logging-data="3277109"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/cSG4STDttVsSKkoyKes51"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:8wHnhbWbm069fo904k5PdaR/S6Y=
	sha1:vtepmHngTpACtsuSPr8xpyi4OZk=
Bytes: 4080

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 09/08/2024 01:14, Keith Thompson wrote:
>>>
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>> [...]
>>>>
>>>>> A _Bool is always either 0 or 1.  The conversion is whatever the
>>>>> compiler needs to give an int of value 0 or 1.
>>>>
>>>> The value of a _Bool object is always either 0 or 1 *unless* the
>>>> program does something weird.
>>>
>>> True.  But attempting to use a _Bool object (as a _Bool) that does not
>>> contain either 0 or 1 is going to be undefined behaviour (at least it
>>> was on the platform where I saw this happen as a code bug).
>>
>> It depends on whether representations with non-zero padding bits are
>> treated as trap representations (non-value representations in C23) or
>> not.
>
> In C99 and C11, iirc, the width of _Bool may be any value between
> 1 and CHAR_BIT.  If the width of _Bool is greater than 1, a _Bool
> may have a well-defined value that is neither 0 or 1.  My guess is
> most implementations define the width of _Bool as 1, but they don't
> have to (again, iirc, in C99 and C11).

C11 (N1570) isn't 100% clear, but I think you're right.  The conversion
rank of _Bool is less than the rank of the char types.  I don't see an
explicit statement that this implies that _Bool has less precision than
unsigned char, so conceivably a conforming implementation could give
_Bool a precision of 2*CHAR_BIT, but C23 has cleared this up so I'm not
going to worry about it (and it's possible I've missed something).

>>>> It doesn't specify whether setting the padding bits to 1 results in a
>>>> non-value representation.
>>>
>>> That's probably an implementation-defined issue, is it not?
>>
>> I'm not sure whether it's implementation-defined or unspecified.
>> I don't see any mention of trap/non-value representations in Annex J.
>>
>> [...]
>
> 6.2.6.1 p 2;

So it's implementation-defined.

N1570 :

    Except for bit-fields, objects are composed of contiguous sequences of
    one or more bytes, the number, order, and encoding of which are either
    explicitly specified or implementation-defined.

> J.3.13 p 1, third subpoint.

    The number, order, and encoding of bytes in any object (when not
    explicitly specified in this International Standard) (6.2.6.1).

(listed under Implementation-defined behavior).

Quoting the standard so that everyone else doesn't have to go look it up
(and guess which edition you're referring to).  You might consider doing
that yourself.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */