enum function bug?

[karl at haddock]

sdchem!tps (Tom Stockfisch) writes:
>I want to pass a pointer to function returning [enum bool] to a function,
>but lint says I'm not doing it right.

Cc and lint disagree about what "enum" really means.  Lint calls it a new
datatype, but cc thinks it's just a synonym for "int" in some contexts.
Apparently the distinction is lost somewhere between lint pass 1 and pass 2.
Yes, it's a bug.

#if SOAPBOX
I think cc should also treat them as distinct types.  (The easy-going days
of "everything is an int" are over, folks.  Egad, now you have to *declare*
functions, even if you're just passing the result to another function!)
If you need an int context, you should cast the enum into an int.  (Though
switch(enum) should still work, provided all the case labels are enums.)  I
suppose an enum actually specifies an *ordered* set, so "++" and "--" are
acceptable, as well as "+" and "-", but they work as with pointers: enum+int
== enum, enum-enum == int.

This proposal would make your "enum bool" less useful, but "typedef int bool"
(which is what I always use) is just as good anyway.

The only addition I'd like to make is to allow one to declare an array to be
subscripted by an enum: "double foo[enum color]; foo[RED] = 1.0; ...".  Such
an array would *not* be subscriptable by int (though of course an integral
expression could be cast into enum color and then used as a subscript).  This
would often obviate the need for a constant NCOLORS, and make the code more
palatable to both cc and lint.  A smart compiler could make a special case
for sparse enums (enum color { RED=0, BLUE=100 }), as long as it's guaranteed
that each valid instance of the enum type may be used as a subscript.

The idea could be extended to allow any datatype, e.g. "int foo[char]" (which
would subscript from -128 to 127 on a pdp11 or vax), but this is less useful.
#endif /* SOAPBOX */

Karl W. Z. Heuer (ima!haddock!karl; karl at haddock.isc.com), The Walking Lint