Bit-fields

[Jim Dehnert]

> From: Mark Mitchell <mark at codesourcery.com>
> 
> It seems to me that our handling of over-sized bitfields is a bit
> over-generous.  For example, given:
> 
>   char c : 128;
> 
> we'll align the bitfield as for a `long long', even though the
> standard specifically says the extra bits are ignored.  You can't take
> the address of a bitfield (even though in our ABI it will be aligned),
> so it's not even legal to take the address, cast it to some very long
> type, and make use of the storage -- there's no way to get the offset
> of the bitfield.  Why not just align this on a `char' boundary?

Because the only rationale anyone could remember for defining this
capability in C++, and the best one we could uncover for using it,
was the following:

	typedef enum { ... } E;
	class C {
	  ...
	  E e: 32;
	  ...
	};

The standard allows the compiler to allocate an E to any size type that
will hold it.  So if one wants to write such a class with a guarantee
of the size of field 'e', the bitfield syntax is required.  We felt
that extending this to the alignment treatment we chose finished that
job, and was a more concrete rationale than anything else we could come
up with.  If the user wants a minimally aligned bitfield, he can still
use the small type followed by an unnamed bitfield.

Jim

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272