Path: csiph.com!news.neodome.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Representation of _Bool Date: Mon, 24 May 2021 06:49:19 -0700 Organization: A noiseless patient Spider Lines: 62 Message-ID: <86bl90dyxs.fsf@linuxsc.com> References: <87tums515a.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="c782108abdd51aa6a9613843ec6dd46d"; logging-data="22922"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+idS3aDBECNe9ekh8OQCB/2GGmd9Wb27U=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:U8FVew1BxfI0a8z1J0hnXhd8jHc= sha1:vWNkuRdQsRrDlbig6lMxd4jUbT4= Xref: csiph.com comp.lang.c:161100 Keith Thompson writes: > As promised, I've studied what the C standard says about the > requirements for the representation of _Bool. I've referred to the > C11 standard and to drafts of C17 and C2x (N2596). C11 and C17 do > not differ in this area as far as I can tell, but there are some > new things in the C2x proposal. Thank you, this looks good (and nice to have C17 and C2x included). > [...] > > The rank of _Bool shall be less than the rank of all other standard > integer types. This implies that the range of values of _Bool is > a subrange of the range of values of unsigned char. A _Bool object > cannot store a value less than 0 or greater than UCHAR_MAX. AFAICT the width of _Bool is permitted to be greater than the width of an extended unsigned integer type whose width is less than CHAR_BIT. It seems weird to allow that, but I don't see anything that forbids it. > [...] > > Here's a small program that attempts to explore how an implementation > represents objects of type _Bool: > > [..program..] > > [..gcc results and analysis..] So I conclude that > for gcc, 2 and 3 (and probably anything other than 0 or 1) are > trap representations for _Bool, and that _Bool has 1 value bit, > 7 padding bits, and 254 trap representation. Yes I believe that's right. > It's possible that the intent is for _Bool to have 8 value bits and the > gcc authors' interpretation of the requirements for simple assignment > differ from mine. (I won't presume to say who's right.) Other evidence suggests gcc takes the width of _Bool to be 1. See below. > [..clang results and analysis..] > It's not consistent with _Bool having more than 1 value bit. There could be another value bit that is not adjacent to the low order bit, with a padding bit inbetween. Of course, it is highly unlikely that that is the case. > When implementers add support for BOOL_WIDTH, they'll have to decide > explicitly how many value bits _Bool has. I think other parts of the language necessitate the decision having been made, even without BOOL_WIDTH. Both gcc and clang take the width of _Bool to be 1, as may be seen by compiling the following program: struct { _Bool just_checking : 2; } test;