Re: RFC: attribute "unpadded"

[Richard Earnshaw <rearnsha at arm dot com>]

> I want to create a new type attribute "unpadded" that would, on
> this code:
> 
>   struct S __attribute__((unpadded)) {
>     int i;
>     char c;
>   };
> 
> define S to have size 5 and alignment 4 on an ILP32 machine.
> 
> The idea is that the normal tail padding of S (the three bytes
> after "c" to round it out to a multiple of the alignment) would
> be suppressed.  It would be illegal to create arrays of these
> types, since the required alignment would not then be provided
> to all of the array elements.
> 
> The motivation for this comes from work on the C++ ABI, including
> the tests for interoperability that we are developing.  The C++
> ABI essentially has types like the above, but they are implicit.
> Making them explicit gives us a way to express the same thing in C.
> 
> This comes up in C++ like so:
> 
>   struct A { virtual void f();  char c; };
>   struct B : public A { char c2 };
> 
> Here, the size of B is 8, not 12, because "c2" is packed into
> the tail padding of A.  If A were "unpadded", you could express
> this in C as:
> 
>   struct A __attribute__((unpadded)) { void *vptr; char c; };
>   struct B { struct A __base; char c2; };
> 
> If I do not here objections, I will create a patch for this and
> check it in shortly.  Rats, we are in Stage 3 -- so I will check
> it in after we branch for GCC 3.3.
> 
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.

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.

(We could even define sizeof (struct A[1]) to return the padded size.)

R.