Re: RFC: attribute "unpadded"

[Richard Earnshaw <rearnsha at arm dot com>]

> On 28-Aug-2002, Richard Earnshaw <rearnsha@arm.com> wrote:
> > > 
> > > > 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)).
> 
> True.  However, silently breaking common C idioms is usually not a very
> good idea, even if they are only broken for specially annotated types,
> since it is error-prone -- programmers may accidentally make use of the
> common idiom even in cases when it doesn't work.
> 
> This is especially likely for programs which use have significant code
> reuse using templates or the C preprocessor.
> 
> It is important to forbid pointer arithmetic on pointers to unpadded types,
> IMHO, because this is necessary to catch such breakage.

Pointer arithmetic wouldn't be broken, only <num_elt> * 
sizeof(unpadded_type).

That is

	unpadded_type *f;

	f++;

would be defined to be equivalent to

	f = (unpadded_type *)(((char *)f) + sizeof (unpadded_type[1]));

I think sizeof (*f) should also return the padded size.

R.