This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Empty structures: Legal as GNU extension?
- To: egcs at cygnus dot com
- Subject: Re: Empty structures: Legal as GNU extension?
- From: Nathan Myers <ncm at nospam dot cantrip dot org>
- Date: Fri, 07 Aug 1998 19:51:57 -0700
- Newsgroups: cygnus.egcs,comp.os.linux.development.system
- Organization: http://www.cantrip.org/
- References: <35CA1888.31736DE6@cygnus.com>, <199808071230.IAA26367.cygnus.egcs@pincoya.inf.utfsm.cl>
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