Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #161144
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Representation of _Bool |
| Date | 2021-05-24 13:30 -0700 |
| Organization | None to speak of |
| Message-ID | <87eedv50yb.fsf@nosuchdomain.example.com> (permalink) |
| References | <87tums515a.fsf@nosuchdomain.example.com> <86bl90dyxs.fsf@linuxsc.com> |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> 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 */
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar
Representation of _Bool Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-23 19:14 -0700
Re: Representation of _Bool Philipp Klaus Krause <pkk@spth.de> - 2021-05-25 11:40 +0200
Re: Representation of _Bool Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-05-24 12:11 +0100
Re: Representation of _Bool Richard Damon <Richard@Damon-Family.org> - 2021-05-24 07:43 -0400
Re: Representation of _Bool Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-05-24 17:27 +0100
Re: Representation of _Bool Vir Campestris <vir.campestris@invalid.invalid> - 2021-05-25 21:20 +0100
Re: Representation of _Bool Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-24 13:15 -0700
Re: Representation of _Bool Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-05-24 06:49 -0700
Re: Representation of _Bool Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-24 13:30 -0700
Re: Representation of _Bool jacobnavia <jacob@jacob.remcomp.fr> - 2021-05-24 18:40 +0200
Re: Representation of _Bool David Brown <david.brown@hesbynett.no> - 2021-05-24 18:55 +0200
Re: Representation of _Bool Bart <bc@freeuk.com> - 2021-05-24 18:31 +0100
csiph-web