Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: how cast works? Date: Tue, 03 Sep 2024 06:02:20 -0700 Organization: A noiseless patient Spider Lines: 67 Message-ID: <865xrcq49v.fsf@linuxsc.com> References: <20240808193203.00006287@yahoo.com> <87frre8v5q.fsf@nosuchdomain.example.com> <87ttft7bei.fsf@nosuchdomain.example.com> <86frrak3hf.fsf@linuxsc.com> <87plqee8li.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Tue, 03 Sep 2024 15:02:21 +0200 (CEST) Injection-Info: dont-email.me; posting-host="5dc3c968fdc353e2fd687882edf89fc4"; logging-data="3505173"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX187K5o7kz2uMpxh5E1l/MLra04UE/5BmCc=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:ApDoqyrVqvmdNfaa+nVXoSb4yDs= sha1:5FltdP82ThnDnF5G5KAVPKw4wqs= Xref: csiph.com comp.lang.c:388107 Keith Thompson writes: > Tim Rentsch writes: > >> Keith Thompson writes: >> >>> David Brown writes: >>> >>>> On 09/08/2024 01:14, Keith Thompson wrote: >>>> >>>>> David Brown 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, [...] C11 (and I think also C99, but I haven't checked that) states requirements that guarantee _Bool has a width no larger than the width of unsigned char. I'm sure you can locate the relevant passages. >>>>> 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. [...] > > 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. I choose the contents of my comments to be what I think is appropropriate under each individual set of circumstances. Please keep your patronizing preaching to yourself.