Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.lang.c
Subject: Re: How should 'enum's work?
Message-ID: <5495@brl-tgr.ARPA>
Date: Mon, 29-Oct-84 00:12:28 EST
Article-I.D.: brl-tgr.5495
Posted: Mon Oct 29 00:12:28 1984
Date-Received: Tue, 30-Oct-84 01:18:17 EST
References: <9576@watmath.UUCP>
Organization: Ballistic Research Lab
Lines: 20

> ... (although you should
> have to name 100 to ensure that the variable has enough range)

I like all Kevin's suggestions on enums before this one.  enum++
where there is no "next" value is no worse than pointer++.  Perhaps
pointer++ past the valid range should be outlawed (I have seen it
cause subtle bugs, including in the PDP-11 C compiler), but doing
this would outlaw a vast amount of existing code.

> If you want to get fancy, you could enforce that *only* the enum type
> used in the dimension of an array declaration may be used to subscript
> that particular array...

Eh?  What syntax for array declarations are we talking about here?

> The conversion of an enum to char * through a direct cast should yield
> a string giving the enum identifier.

This would require storing all the enum names in run-time data space.
It would also be a rule unlike any other in C.  I vote against this one.