A-25 Bitfields of greater than field size

[Jason Merrill]

dehnert at baalbek.engr.sgi.com (Jim Dehnert) writes:

> > From: Jason Merrill <jason at cygnus.com>
> > Date: 10 Feb 2000 12:43:55 -0800
> > 
> > It seems to me that
> > 
> > struct A {
> >   ...
> >   signed char c: 32;
> >   ...
> > };
> > 
> > should be treated like
> > 
> > struct A {
> >   ...
> >   int i: 32;
> >   ...
> > };
> > 
> > except that only the low 8 bits are significant.  This should be true
> > whether or not there is actually a 32-bit type on the target.
> 
> In fact, I had been thinking that IF the primary purpose of this feature
> is to allow known layout of (something like) an enum type without
> knowing how big the compiler will make it, then Jason is right.
> Specifically, the allocation of the field _with_ padding should be
> based on the largest type that could fit in the specified size.
> Where the real data goes (if there's a choice) doesn't much matter
> then.  Lowest address would work (and lead to a consistent offset
> and/or address).

Note that by "low 8 bits" I meant "least significant 8 bits"; the
position would depend on the endianness of the target.

In other words, you should be able to load the larger type and
truncate it to the smaller type to get the right answer.

Jason