enum function bug?

[Dick Dunn]

In article <86900054 at haddock>, karl at haddock writes:
> 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.
>...
> #if SOAPBOX
> I think cc should also treat them as distinct types.  (The easy-going days
> of "everything is an int" are over, folks...

The problem goes a little deeper than this.  Consider that if an enum is
defined in a .h file, and that header file is used in two separate .c
files, you have (by some annoyingly reasonable argument) two separate
types!  [Substitute canonical discussion of name equivalence vs structural
equivalence of types here.]

If lint were to make a name-equivalence type check, you couldn't use enums
across modules.  I suspect that it is not currently equipped to do the
structural-equivalence test, although it's not that hard to do since
there's no nesting or recursive structure in enums.  But even then,
explicit assignment of ordinals to enum elements, where the ordinals might
be constant expressions (yes, bleah, but read on...) adds more worms to the
can.  Consider something silly like:

----------foo.h:
typedef enum {a=XCONST, b, c} etype;

----------gleep.c
#define	YCONST	3
#define	XCONST	YCONST+YCONST
#include "foo.h"
etype xyzzy = b;

----------mumble.c
#define	YCONST	3
#define	XCONST	2*YCONST
#include "foo.h"
extern etype xyzzy;

Do the types of xyzzy in mumble.c and gleep.c match?  They are provably
both enums with the same type name and the same constituents with the same
values, but...

If you admit that name equivalence is inadequate (which I believe) but that
this example carries structural equivalence too far (which I also believe,
I think), then where do you draw the line?
-- 
Dick Dunn    {hao,ucbvax,allegra,seismo}!nbires!rcd	(303)444-5710 x3086
   ...Are you making this up as you go along?