rfg@pink.ACA.MCC.COM (Ron Guilmette) (06/19/89)
Back in the bad old dayz, when we all used C and knew not of strict
typing rules, travesties like the following were perfectly legal
(and probably still are in ANSI C):
--------------------------------------------------------------------
enum color { red = 7, green = 11, blue = 9 };
color c;
int main ()
{
for (c = 0; c <= blue; c++)
continue;
}
---------------------------------------------------------------------
Interestingly, GNU G++ (1.35.0) eats this up without even a warning.
Could some kind soul tell me what Cfront 2.0 does with it?
I see *at least* three things which I consider errors here.
1) The "c" variable is initialized (in the for loop) to a
non-color value.
2) An (ordered) comparison operator is inappropriately used
to compare two values of a potentially *unordered* type
(i.e. the type "color"). Who sez that all enum types
represent types for which an ordering applies? Ask
yourself "Is blue really greater than red?"
3) The postfix operator ++ is applied to (what I consider to
be) a non-integral type variable. This is the same issue
as (2) above, i.e. "Is there an ordering for colors?"
Another way of saying this is "Does it make any sense to
increment a color?"
All three of these (apparent) errors would still be errors even if
the declaration of color had been simply:
enum color { red, green, blue };
The fact that my initial example included "representation specifications"
(to borrow an Ada term) for the values of type color, simply makes the
(apparent) errors more "glaring".
--
// Ron Guilmette - MCC - Experimental Systems Kit Project
// 3500 West Balcones Center Drive, Austin, TX 78759 - (512)338-3740
// ARPA: rfg@mcc.com
// UUCP: {rutgers,uunet,gatech,ames,pyramid}!cs.utexas.edu!pp!rfgdmg@ssc-vax.UUCP (David Geary) (06/20/89)
In article <254@pink.ACA.MCC.COM>, Ron Guilmette writes:
+ Back in the bad old dayz, when we all used C and knew not of strict
+ typing rules, travesties like the following were perfectly legal
+ (and probably still are in ANSI C):
Yes, the code below is perfectly legal in ANSI C
+
+ --------------------------------------------------------------------
+ enum color { red = 7, green = 11, blue = 9 };
+
+ color c;
+
+ int main ()
+ {
+ for (c = 0; c <= blue; c++)
+ continue;
+ }
+ ---------------------------------------------------------------------
+
+ Interestingly, GNU G++ (1.35.0) eats this up without even a warning.
+ Could some kind soul tell me what Cfront 2.0 does with it?
+
+ I see *at least* three things which I consider errors here.
Well, the three things below are not really errors:
+
+ 1) The "c" variable is initialized (in the for loop) to a
+ non-color value.
According to K&RV2, page 39:
"Although variables of enum types may be declared, compilers need
not check that what you store in such a variable is a valid value
for the enumeration. Nevertheless, enumeration variables offer
the *chance* of checking and so are often better than #defines."
(emphasis on chance is mine)
+
+ 2) An (ordered) comparison operator is inappropriately used
+ to compare two values of a potentially *unordered* type
+ (i.e. the type "color"). Who sez that all enum types
+ represent types for which an ordering applies? Ask
+ yourself "Is blue really greater than red?"
Yes, blue is really greater than red, because enumerated types
have type int. Declaring an enumerated type does not create a new
type, blue and red are still int constants.
+
+ 3) The postfix operator ++ is applied to (what I consider to
+ be) a non-integral type variable. This is the same issue
+ as (2) above, i.e. "Is there an ordering for colors?"
+ Another way of saying this is "Does it make any sense to
+ increment a color?"
Since enumerated types are ints, it makes sense to be able to
apply ++.
+
+ All three of these (apparent) errors would still be errors even if
+ the declaration of color had been simply:
+
+ enum color { red, green, blue };
+
+ The fact that my initial example included "representation specifications"
+ (to borrow an Ada term) for the values of type color, simply makes the
+ (apparent) errors more "glaring".
+
Well, they are not errors (apparent or not). Enumerated types are
really not "fully" supported in either C or C++ as far as I'm
concerned. Enumerated types do not create new types; they are
just ints, and the compiler doesn't have to check the values of
enumerated types if it doesn't want to.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ David Geary, Boeing Aerospace, Seattle ~
~ "I wish I lived where it *only* rains 364 days a year" ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~