Possible C++ bug: Are C enum tags unsigned?
Zack Weinberg
zack@wolery.cumb.org
Sat Jun 10 00:48:00 GMT 2000
On Sat, Jun 10, 2000 at 01:41:31AM -0400, Eli Zaretskii wrote:
> > Date: Fri, 9 Jun 2000 13:55:31 -0700
> > From: Chip Salzenberg <chip@valinux.com>
> >
> > I ask because gcc is reporting a signed/unsigned comparison on line
> > 449 of gcc/cp/cfns.h:
> >
> > 449: else if (index < -TOTAL_KEYWORDS)
> >
> > Now, 'index' is of type 'int', and thus signed. So, by a process of
> > elimination, I deduce that TOTAL_KEYWORDS is unsigned. (And, of
> > course, arithmetic negation of an unsigned value is also unsigned.)
> >
> > Two questions: (1) Are enum tags _supposed_ to be unsigned?
It's implementation-defined. I believe GCC chooses to make enum tags
unsigned iff the enum has no negative entries.
> > (2) If so, is this line buggy, or not?
This is machine-generated code and I'm not sure what it is trying to
achieve. I believe it does not make a difference whether
TOTAL_KEYWORDS is signed or not in this context, but I could be wrong.
> The problem is in your code: you are abusing the enum type by
> comparing it against an int
I'm sorry, this is nonsense
> and by negating it.
and this is debatable.
> The only operations which can meaningfully be used with an enum are
> assignment, equality, and inequality. And you cannot mix enum with
> other data types, so the above comparison has an undefined result.
This may be true in some language other than C. In C an enumeration
tag is an integer constant. It is legal to do anything with it that
may be done with any other integer constant. And it does *not* have
its own type. The implementation gets to pick which one, but it will
be a normal integer type.
It is a common idiom to use enums just as one would use #defined
constants, and that is exactly what gperf is doing here. From the
manpage:
-E, --enum
Define constant values using an enum local to the
lookup function rather than with #defines. This
also means that different lookup functions can
reside in the same file. Thanks to James Clark
`<jjc@ai.mit.edu>'.
zw
More information about the Gcc-bugs
mailing list