Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson 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: <20240808193203.00006287@yahoo.com> <87frre8v5q.fsf@nosuchdomain.example.com> <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 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, 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 */