This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: underlying type for enums
Richard Henderson <rth@redhat.com> writes:
...
> As for the rest of your question, it depends on how C90 interprets
> the type of "int foo:8". I'll go into the office today and locate
> my dead tree edition of C90...
I've got my dead tree edition right here, so...
The relevant bit is paragraph 8 of 6.5.2.1:
[semantics]
8 A bit-field shall have a type that is a qualified or unqualified
version of one of {int}, {unsigned int}, or {signed int}. Whether
or not the high-order bit position of a (possibly qualified) "plain"
{int} bit-field is treated as a sign bit is implementation-defined.
A bit-field is interpreted as an integral type consisting of the
specified number of bits.
Compare C99 6.7.2.1pp4,9:
[constraints]
4 A bit-field shall have a type that is a qualified or unqualified
version of {_Bool}, {signed int}, {unsigned int}, or some other
implementation-defined type.
[semantics]
9 A bit-field is interpreted as a signed or unsigned integer type
consisting of the specified number of bits.(104) [... something
weird about _Bool that I don't get]
(footnote 104)
As specified in 6.7.2[p5] above, if the actual type specifier
used is {int} or a typedef-name defined as {int}, then it is
implementation-defined whether the bit-field is signed or unsigned.
(braces indicate typewriter font)
I *think* this means the enum bit-field extension can be treated
identically under both C90 and C99. Under C90, we've relaxed a
"shall" in a non-constraint section. Under C99, we've taken
advantage of the "some other implementation-defined type" loophole.
Either way, it's an "integral type consisting of the specified number
of bits" which is just what we want.
Thoughts?
zw