Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Representation of _Bool Date: Mon, 24 May 2021 13:30:36 -0700 Organization: None to speak of Lines: 84 Message-ID: <87eedv50yb.fsf@nosuchdomain.example.com> References: <87tums515a.fsf@nosuchdomain.example.com> <86bl90dyxs.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="515a578b1fbda6d2e69cf5c5ac94ed10"; logging-data="9686"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19AlY5/FJHuZo941inoVTDL" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:6VRm6e44QexPmjXBJOCMhbBcPcw= sha1:twEKoyRExs1fgVZ/nQPBOvbWJWo= Xref: csiph.com comp.lang.c:161144 Tim Rentsch writes: > 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. For example, an implementation might have an extended integer type _Nybble with 4 value bits. I'll look into that. >> [...] >> >> 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; Right, C11 6.7.2.1p4: The expression that specifies the width of a bit-field shall be an integer constant expression with a nonnegative value that does not exceed the width of an object of the type that would be specified were the colon and expression omitted. I even cited the footnote on that paragraph, but missed the paragraph itself. Both clang and gcc (latest versions) complain that the width of the bit field exceeds that of its type, so they both have a width of 1 for _Bool. I'll spend some time later looking into the question of trap representations. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */