Re: RFC: attribute "unpadded"

[kaih at khms dot westfalen dot de (Kai Henningsen)]

mark@codesourcery.com (Mark Mitchell)  wrote on 29.08.02 in <17800000.1030660041@warlock.codesourcery.com>:

> > 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.
>
> Yes.  Most front ends (sample of 4) actually create both types, although
> they do:
>
>   struct A { void *__vptr; char c; };
>
> rather than:
>
>   struct A { struct __A body; }
>
> I'm not sure if there's ever a case where that matters.
>
> If there is a virtual base "V" then the full "A" looks like:
>
>   struct A { void *__vptr; char c; struct __V vbase; };
>
> Some front ends do this because their back ends expect all types to
> be basically C types.

So then it seems to me that a reasonably sane model of this for C would be  
to make an unpadded type be similar to an incomplete type, *except* that  
it can be used as a structure field (and possibly that we can dereference  
its fields from a pointer to it).

Can't use it to construct a variable or an array, same as you can't with  
an incomplete type. Can have pointers to it as long as you don't try  
pointer arithmetic, but again that should be the same as with an  
incomplete type.

Incomplete types can't sizeof(); no idea if it would be wiser to allow or  
forbid this for unpadded types.

Summary: an unpadded struct type is the same as an incomplete struct type,  
except there are a very few things more that can be done with it (and that  
can easily be enumerated in the docs) - *not* a complete struct type with  
a number of hard-to-predict things that you can't do with it.

MfG Kai