Re: RFC: attribute "unpadded"

[Fergus Henderson <fjh at cs dot mu dot OZ dot AU>]

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.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.