enum function bug?

[Guido van Rossum]

In article <572 at opus.nbires.UUCP> rcd at nbires.UUCP (Dick Dunn) writes:
>[example with enum {a= 3+3, b, c} in one file and enum {a= 2*3, b, c}
>in another]
>
>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?

In my eyes, in the example you give the two types are clearly
structurally equivalent.  After all, the two expressions have to be
constant expressions, which is a well-defined term (in C!).  I propose
the following rule for enum equivalence:

	Two enumerated types are equivalent if they have the same 'tag'
	(or no tags), and define the same set of enumeration constants
	with the same associated value for each constant.

(This will find even enum {a=2, b=1, c=0} and enum {c, b, a} equivalent!)

By the way, I agree with the proposed ANSI standard which defines that
enums are equivalent to ints!  This is the only suitable way to do it
*in C*, even though for any other language, to be designed newly, enums
should be distinct types.  I also agree with Lint checking enum
equivalence -- but there should be a way to turn it off, since I believe
that lint should not issue any errors (warnings are ok) for strictly
ANSI-conforming C programs.
-- 
	Guido van Rossum, CWI, Amsterdam <guido at mcvax.uucp>