Re: RFC: attribute "unpadded"

[Richard Henderson <rth at redhat dot com>]

On Mon, Aug 26, 2002 at 09:38:50AM -0700, Mark Mitchell wrote:
> However, it is the one extension that will naturally express the thing
> that the C++ ABI does; that ABI creates types whose sizes are not multiples
> of their alignments by ignoring tail padding.

But it doesn't really do that, does it?

	struct A { virtual void foo(); char c; };
	struct B : public A { char d; };

sizeof(class A) is still 8, isn't it?  You can still make arrays
of type A.  What the ABI seems to actually do is include members
directly.  I.e. the C equivalent is *not*

	struct B { struct A __base; char d; };

but rather

	struct B { void *__vptr; char c; char d; };

which more or less naturally handles tail padding as you like.
And which is _somewhat_ remeniscent of the now-deprecated MSVC
extension

	struct B { struct A; char d; };

(I'm not actually sure what MSVC would say about sizeof(B) here,
and the relevant test case, gcc.dg/anon-struct-3.c, uses chars.
FWIW, gcc currently sets sizeof(struct B) == 12.)

Or perhaps you see the ABI creating intermediate types, such as

	struct __A { void *__vptr; char c; } attribute((unpadded));
	struct A { struct __A body; };
	struct B { struct __A base; char d; };

In this modified form, A is correctly sized for an array,
though __A is not.

Perhaps you could elaborate further on the distinction here?


r~