This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: enum xyz;
- To: gdb@sourceware.cygnus.com
- Subject: Re: enum xyz;
- From: jtc@redback.com (J.T. Conklin)
- Date: 09 Aug 1999 11:05:24 -0700
- References: <199908091549.LAA03778@texas.cygnus.com>
- Reply-To: jtc@redback.com
>>>>> "David" == David Taylor <taylor@cygnus.com> writes:
David> The standard explicitly states that incomplete enums types are
David> not permitted. If need be I can dig out the standard and find
David> the specific section that states this.
[ Disclaimer: I no longer have a copy of the C standard handy, but I
had a enum related issue at work I had to track down a few weeks
back so I grabbed a copy of one of the C9X drafts from the web.
I'm not absolutly certain that this applies to C89... ]
One reason that may explain why incomplete enums are not permitted is
the fact that a compiler is allowed to defer determining the storage
size (and thus alignment) of an enum until it is defined. Since the
only thing you can do with an incomplete type is to use it to define
a pointer, an indeterminate storage size would lose on machines that
have different pointer representations for different sized data
objects.
In fact, as I wrote this message, I came to realize that incomplete
enums lose even on machines with single pointer representation. For
example, in the following code, a compiler that uses different storage
sizes for enums would not know how much to copy.
enum foo;
struct bar {
enum foo *bar;
...
};
struct baz {
enum foo *baz;
...
};
{
...
*bar->foo == *baz->foo;
...
}
And to think that some years ago I thought it was stupid to have
incomplete structs and unions and not have incomplete enums...
--jtc
--
J.T. Conklin
RedBack Networks