Path: utzoo!mnetor!uunet!husc6!purdue!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: typedef laxity
Message-ID: <11108@mimsy.UUCP>
Date: 18 Apr 88 22:56:15 GMT
References: <1070@maynard.BSW.COM> <757@xyzzy.UUCP> <759@xyzzy.UUCP> <796@xyzzy.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 29

In article <796@xyzzy.UUCP> throopw@xyzzy.UUCP (Wayne A. Throop) writes:
>[enumerated types] may not be "distinct" (in the sense of requiring
>a warning) from the integer type they are guaranteed to be "compatible"
>with under the rules for enumerations.  Note that this would account
>for the distinctness of enumerated types ....

As it happens, the most recent 4BSD compilers work this way.  For
instance, fed the following, cc complains about lines 8 and 10:

	1	enum pressure { p_low = 0, p_high = 760 };
	2	enum temperature { t_low = -273, t_high = 100 };
	3	f() {
	4		enum pressure p;
	5		enum temperature t;
	6		p = p_low;
	7		t = t_high;
	8		p = t_high;
	9		p = 100;
	10		p = t;
	11	}

This turns out to be quite easy to implement.  The routine `chkpun' is
the place where type clashes are noticed.  If either part of some
operator is an enumerated types, then if both are enumerations but the
two are not the same, complain; otherwise, pretend any enumerated type
is an |int|, and perform the usual tests (pointer vs integer, etc.).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris