Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #161100

Re: Representation of _Bool

Show all headers | View raw

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.

> [...]
>
> 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;

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

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