Bitfields of greater than field size

[Jim Dehnert]

> To: mendell at ca.ibm.com
> Subject: Re: Bitfields of greater than field size
> Reply-To: Martin von Loewis <loewis at informatik.hu-berlin.de>
> 
> > I have been told that the standard allows:
> > 
> > struct foo {
> >      long xx : 128;
> > };
> 
> > This is a field that takes up 128 bits of space, but only really
> > uses sizeof(long) * 8 bits.  We have to agree on where the padding
> > goes.  I couldn't find it in the data layout spec.
> > Our compiler puts it after the 'real' bits.
> 
> Isn't that already specified by the base API (gABI, psABI)? (not that
> I have access to the base API...)

I've never seen this in an ABI.  I just verified that this is
explicitly forbidden by the C 2000 draft standard, which would explain
its absence in C ABIs.  I also verified that it is explicitly allowed
by the C++ standard, with the excess being treated as inaccessible
padding, making it a valid concern of our C++ ABI.  I'll open an issue.
Would someone care to write up a careful discussion of the issues?
It seems to me that the situation that makes it interesting is the
following:

	struct s {
	  short s1;
	  int i: 64;
	  short s2;
	}

In this case, I don't want the accessible part of i at the beginning or
the end -- I want it in the middle.  Doing otherwise gives me either a
badly aligned i, or wasted space.

I think one could express this by the following rule:

	Place the accessible part of the bitfield object as if
	it were a non-bitfield member of the declared type, i.e.
	at the next available offset of the appropriate alignment.
	Allocate the full bitfield at the earliest available
	offset where it will include the accessible part.

Jim

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