Bitfields of greater than field size

[mendell at ca.ibm.com]

I disagree.  If the user wants the bitfield to be aligned in a certain
place, he
 has the tools to do so.  He can certainly pick a different size bitfield.
I think that this should be aligned as if it is the same size as the type,
and then
the extra bits put somewhere.  Putting them afterwards is probably simpler
than before, or splitting it in the middle.

Mark



dehnert at baalbek.engr.sgi.com (Jim Dehnert) on 02/04/2000 04:27:18 PM

Please respond to dehnert at sgi.com

To:   Mark Mendell/Toronto/IBM at IBMCA, Martin von Loewis
      <loewis at informatik.hu-berlin.de>
cc:   cxx-abi at corp.sgi.com
Subject:  Re: Bitfields of greater than field size




> 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