[cfe-dev] patch: boolean bitfield init

Daniel Dunbar daniel at zuster.org
Thu Jul 17 18:24:16 PDT 2008


I'm fairly sure that gcc is treating _Bool as an unsigned char as widths
1-8 work and allow the full range of values, but I haven't checked the 
gcc implementation yet. For C++ g++ appears to treat it as padding as
you describe.

----- Original Message ----
From: Eli Friedman <eli.friedman at gmail.com>
To: Daniel Dunbar <daniel at zuster.org>
Cc: Chris Lattner <clattner at apple.com>; cfe-dev at cs.uiuc.edu
Sent: Thursday, July 17, 2008 6:03:30 PM
Subject: Re: [cfe-dev] patch: boolean bitfield init

On Thu, Jul 17, 2008 at 11:14 AM, Daniel Dunbar <daniel at zuster.org> wrote:
> The immediate problem is that the constant being used to initialize
> the bit-field is of type bool (this is a separate bug) even though the bit-
> field has width > 1. This breaks the algorithm used to initialize the struct
> because it expects to be able to extract all the required bits from the
> constant.

Yeah... that algorithm is actually my code.  As far as I can tell, the
patch is correct, although it seems like overkill to extend the width
of V all the way to the width of the bitfield.

> Most likely the more correct fix is that the initializer on the RHS for field
> 'a' should have type char but this is more invasive. Hence the FIXME
> comment. :)

Here's the situation with relation to the standards: in C99, the code
is illegal, because the bit-field width exceeds the width of the type.
We're missing an diagnostic in Sema for this.  In C++, at least per
the current C++0x draft, the extra bits are treated as padding bits,
so Sema is correct as-is.  The only question is, what the heck gcc is
doing here?  As far as I can tell, it seems to be treating the _Bool
bitfield as a unsigned char bitfield.  Anyone know more?

-Eli




More information about the cfe-dev mailing list