[PATCH] enum handling
commitb598c1d75a9c455c85a894172329941300fcfb9f
authorAlexander Viro <viro@parcelfarce.linux.theplanet.co.uk>
Thu, 30 Sep 2004 16:17:08 +0000 (30 09:17 -0700)
committerLinus Torvalds <torvalds@ppc970.osdl.org>
Fri, 8 Apr 2005 04:03:25 +0000 (7 21:03 -0700)
treefae9da54e8259eb2c3a302a64e051528304c8086
parent2f41db312c29a293866cbd343bc2f76bfe903e62
[PATCH] enum handling

a) we allow enum have an equivalent type other than int (it is kept in
   ->ctype.base_type for SYM_ENUM types).  Code adjusted.

b) enum declaration parsing tries to determine the equivalent type; if
   such type does not exist we set it to &bad_enum_ctype and
   examine_symbol_type() generates a warning when it meets such beast.
   The rules for equivalent type follow:

1) if all members have the same bitwise type, it is the
   equivalent type of enum.
2) if all members have integer types and there is a single
   integer type capable of representing all their values, we pick
   the first such type (in the same ordering that is used for e.g.
   integer constants).
3) anything else => bad_enum_ctype.

c) enum is compatible with its equivalent type.

d) it is an error to have implied initializer for a member following
   that of bitwise type.

There are still issues with float in enums, but since gcc would choke on
those unconditionally, we can be sure that there's no instances in any
code we could deal with (unless we start playing with Plan 9 codebase,
and that would require more work in other places - float enum is not the
only C extension in there).  Separate patch...
evaluate.c
parse.c
symbol.c
symbol.h