Re: RFC: attribute "unpadded"

[Richard Earnshaw <rearnsha at arm dot com>]

> Richard Earnshaw:
> > > > I wonder if we should not just give the type two sizes, an unpadded one 
> > > > and a padded one.  Then the unpadded one would be used for operations such 
> 
> Me:
> > > That would violate C semantics: sizeof() must return the padded length.
> > > If it did not, the common C idiom
> 
> Richard:
> > We've already gone outside the realm of the C standard as soon as we 
> > define __attribute__ ((unpadded)).
> 
> You're right, I was confused.  Objection withdrawn, pardon my stupidity.
> 
> On the other hand, there may be other problems with making arrays of unpadded
> objects.  It almost seems contractory: to find the address of foo[1] we
> consider padding, but we've declared the thing unpadded.
> 

The point of unpadded is that when the type is embedded in a larger one, 
other elements can be located around it without leaving holes if the 
alignment of such elements allow this.  If you want to say in effect that 
"unpadded" types may only be used as elements of larger aggregates, then 
fine, but that seems a little draconian.

My suggestion allows for

struct foo {int a; char b} __attribute__((unpadded));

struct bar {struct foo a1; struct foo a2};

to be written as

struct bar {struct foo a[2]};

and for the layout to be the same (in both cases the padding is placed in 
bar, not in the member types);  without this, the second form must be 
declared illegal.

R.