typedef laxity

[Wayne A. Throop]

> chris at mimsy.UUCP (Chris Torek)
>> throopw at xyzzy.UUCP (Wayne A. Throop)
>>[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.
> 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	}

Note: according to draft X3J11, a compiler has no reason to complain
about the assignment of t_high to p, because t_high is of type (int),
not of type (enum temperature).  I don't object to a lint-like tool
complaining about this, mind you: it's just that under the rules Chris
mentions above, it has no explicit reason to do so.

(Does anybody know *WHY* enumeration member names have integer type?
 This prohibits the reasonable diagnostic above, and at the same time
 limits enumerations to spanning at most (int) and ruling out (long) for
 no particular reason I can discern.)

(Also, does anybody have any comment about using enumermations as
 integer subranges, as the above example implies?  In particular is it
 guarangeed by draft X3J11 that (t=75) must work, or that (t=t_low,++p)
 must insure that ((int)t)==(-272), and all the rest that would make
 subranges useful?)

--
It is a lovely language, but it takes a very long time to say anything
in it, because we do not say anything in it, unless it is worth taking a
long time to say, and to listen to.
                        --- J.R.R. Tolkien
-- 
Wayne Throop      <the-known-world>!mcnc!rti!xyzzy!throopw