This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: attribute "unpadded"
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Joe Buck <Joe dot Buck at synopsys dot com>
- Cc: Richard dot Earnshaw at arm dot com, mark at codesourcery dot com (Mark Mitchell), gcc at gcc dot gnu dot org
- Date: Wed, 28 Aug 2002 18:54:49 +0100
- Subject: Re: RFC: attribute "unpadded"
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
>
> > 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.