Enumerated types... what's the point?

[Jim Giles]

>From article <1990Mar23.234509.21638 at aqdata.uucp>, by sullivan at aqdata.uucp (Michael T. Sullivan):
> [...]
> typedef enum { red, green, brown, yellow } colors;
> typedef enum { huey, dewey, louie } ducks;
> main(){
> colors	a;
> ducks	b;
> 	a = red;
> 	b = huey;
> 	a = 1
> 	a = b;
> }
> produces a compiler error at "a = 1" and "a = b".  This makes sure people 
> can't make an end run around the values a given variable should have,
> which they could easily do if #define's were used for the values.

Really?  The new standard doesn't say that those assignemnts are illegal.
For example:
      "The identifiers in an enumerator list are declared as constants
       that have type int and may appear wherever such are permitted."

So, all the enumeration constants are just type int (in fact, red ==0,
green == 1, brown == 2, yellow == 3, huey == 0, dewey == 1, and
louie == 2).

Furthermore:
      "An object that has an enumeration type behaves like an int in
       an expression.  The implementation may use the set of values
       in the enumeration to determine whether to allocate less storage
       than an int."

In other words, the a and b vars behave as int except they may require
less storage.  So, all the assignments in your example are legal.

J. Giles

Note: The quotes above are from the last public review draft and
      not the new standard.  When (and if) I get a copy of the new
      standard, I will no longer be stuck with a possible source
      of wrong information.  If what I just quoted has been changed
      in the final standard, I want to be told.  There can't have
      been too many changes though since that would have required
      yet another public review.
> Michael Sullivan          uunet!jarthur!aqdata!sullivan
> aQdata, Inc.              sullivan at aqdata.uucp
> San Dimas, CA             +1 714 599 9992