This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Empty structures: Legal as GNU extension?


Horst von Brand wrote:
> Nathan Myers wrote:
> > HvB wrote:
> > > It just so happens that the Linux kernel uses empty structures [...]
> >
> > If support for empty structs isn't documented, it might go away.
> 
> That's exactly what I am worried about.

Worry.  The extended-C struct layout will probably not stay different 
from the standard-conforming C++ layout just to rescue an undocumented
feature.

> > Empty structs are allowed in Standard C++, but might not be really empty.
> > In Egcs-1.1, with -fnew-abi, they are whenever it's allowed.  (Two objects
> > of the same type can't have the same address, so sometimes padding is
> > needed.)  Of course this fact isn't very useful for Linux kernel coding
> > *quite* yet.  Next year, who knows?
> 
> If C++ allows the Linux kernel use (which is exactly as you describe), it
> should be easy to keep it as a C++-like extension, like inline functions
> are. They do share most of their code with C++, don't they? (Yes, I do know
> that inline functions are vastly more useful and much harder to do than
> what I'm asking for).

The structure layout with C++ empty members changed recently -- in 
the "old ABI" they were never really empty; in the new ABI (-fnew-abi) 
they usually are, unless they're adjacent.  The -fnew-abi layout might 
change again, until it becomes the default.  (C++ object layout isn't
standardized, except for legal C structs, and the ABI is being changed
for other reasons, too, such as exception/MT safety.)

The C++ support for empty members might be rolled into the C compiler
as a C extension, but this would give a different layout than is emitted 
now, for some struct definitions.

Probably the safest thing to do is to put a dummy "char" into those empty 
structs; failing that, make sure there are no adjacent empty objects of 
the same type.  This can tricky:

  struct A {};
  struct B { int i; struct A a; };
  struct C { struct A a; int j; };
  struct D { struct B b; struct C c; };

Here B and C are not empty, but we still have two adjacent A's in D, 
which might result in sizeof(D) and offsetof(c.j) being unstable.

Nathan Myers
ncm@nospam.cantrip.org


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]