Re: Why no/limited checking on enum values ?

From: Chris Torek (nospam_at_torek.net)
Date: 01/17/05 

Date: 17 Jan 2005 17:18:18 GMT

>"Nebula" <noname@example.com> wrote in message
>news:41ebca38@news.wineasy.se...
>> Consider
>> enum Side {Back,Front,Top,Bottom};
>> enum Side a;
>> Now, why is
>> a = 124;
>> legal (well it really is an integer, but still,
>> checking could be performed..) ?
>> Wouldn't enums be more useful if there was a
>> bit more typechecking ?

(Some compilers actually do some sort(s) of extra checking. No
diagnostics are required here, but compilers are always allowed to
produce as many warning messages as the compiler-writer wants.
Whether or not those extra warning are good or desirable is another
question entirely....)

In article <W3SGd.8999$pZ4.748@newsread1.news.pas.earthlink.net>
xarax <xarax@email.com> wrote:
>An enum type is a symbolic name for an int. Declaring

Well, not quite. The enumeration *members* are names for "int"s,
but the enumerated *type* -- here "enum Side" -- is not necessarily
an int. Some compilers either always, or optionally, shorten the
type to the smallest one that will hold its members. (With gcc,
use "-fshort-enum" to turn this on.)

>enum Side a;
>
>is simply declaring 'a' to be an int.

Or perhaps a "char" or "unsigned char":

    enum A { Zero, One_twenty_seven = 127 }; /* always fits in char */
    enum B { Two_fifty_five = 255 }; /* always fits in unsigned char */
    enum C { Three_two_seven_six_seven = 32767 }; /* always fits in int */

I have not studied the C99 text closely yet, but my reading of the
C89 standard appears to me to allow even "enum C" to use an unsigned
char, despite the fact that one should be able to do:

    enum C x = Three_two_seven_six_seven;

and on real implementations, that would make x have the value 127.
(I would hope that any compiler that did this, even if the C
standards do allow it, would not survive in the marketplace....)

Note that:

    enum D { Large = 2147483647 };

is OK if and only if INT_MAX is at least 2147483647, e.g., typical
32-bit systems today. In other words, you can use this in a 32-bit
compiler but not in a 16-bit compiler. (I believe some compilers
have extensions to allow "enum"s to contain long and/or long long
members, but this *is* an extension; the C standards -- C89 and
C99 both -- do not require it.) 

-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: forget about it   http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

Relevant Pages

  • Re: Implicit int
    ... reducing bad programming practices in the future (including ... What is the necessity of long long when long int, ... Is this decision taken because *many* ILP32 compilers (which are ... Why should the standards care if a particular implementation is not ...
    (comp.std.c)
  • Re: Delay Routine: Fully-portable C89 if possible
    ... Even nominally C89 compilers frequently support such features. ... language standards say that if a type is expected, ... you don't want to write out "long unsigned int", ... unsigned long int uint32_t" in a common header file - nor does it matter ...
    (comp.arch.embedded)
  • Re: No enumeration data type in Fortran?
    ... compiler that makes one [enum] other than int won't work with a F2003 ... A lot of trouble was put into making f2003 so that it ... compilers that don't make all enums int). ... compilers, and they knew more about the subject than I did or do. ...
    (comp.lang.fortran)
  • Re: enum safety
    ... 'Although variables of enum types may be declared, compilers need not ... In this case, c is of type char*, purple is of type enum ... creates a series of constants (which, oddly enough, are of type int, ...
    (comp.lang.c)
  • Re: resolving a warning error
    ... >This works on several systems and compilers, but fails on aix xlc. ... Not if you invoke them in conforming mode: ... >warning messages and without declaring the enum? ...
    (comp.lang.c)