Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: how cast works?
Date: Sun, 11 Aug 2024 17:07:56 -0700
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <86frrak3hf.fsf@linuxsc.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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Mon, 12 Aug 2024 02:07:57 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f42e4005105099d89c60a754521770ce"; logging-data="3093877"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19suEoVPVwnOfg2sCdTJ8MthrSqcnzUHxo="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:3RfUSTJWfC/6NZAHqynjWdRCH2s= sha1:2l8W/Ej7EM6bdo/p7qX+4GzbHio=
Xref: csiph.com comp.lang.c:387488

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

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

J.3.13 p 1, third subpoint.