[cfe-dev] patch: boolean bitfield init

Chris Lattner clattner at apple.com
Thu Jul 17 21:14:11 PDT 2008

On Jul 17, 2008, at 6:24 PM, Daniel Dunbar wrote:

> 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.

I think the compiler is always required to keep the bool containing 0  
or 1.  The bitfield width allows the user to pack them more densely.   
On Darwin/ppc32 for example, sizeof(_Bool) is 4, which makes  
bitfielding them a very useful thing :)


> ----- 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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

More information about the cfe-dev mailing list