RFC: attribute "unpadded"

[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 
> > as sizeof, and in creating larger records, but the padded one could be 
> > used for arrays and pointer arithmetic operations.  That is, an array 
> > would consist of a series of such structures laid out at their natural 
> > alignment.
> 
> That would violate C semantics: sizeof() must return the padded length.
> If it did not, the common C idiom
> 
> 	struct foo *p = malloc(array_length * sizeof(struct foo));
> 
> would break.

We've already gone outside the realm of the C standard as soon as we 
define __attribute__ ((unpadded)).  Anyway, defining

	struct foo *p = malloc(array_length * sizeof(struct foo[1]));

would work if you used my further suggestion, since struct foo[1] would 
always return the padded size.

> > It does mean that using code such as n * sizeof(struct A) would be 
> > undefined, but it would mean that some array operations would be well 
> > defined.
> 
> But C already specifies the meaning of n * sizeof(struct A) and assures
> that if you pass such an argument to malloc, the result will hold n A's,
> complete with padding.

It doesn't specify *anything* for unpadded types, it isn't part of the 
standard.

R.