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