enum handling by cc under ultrix V2 wrong?

[Richard A. O'Keefe]

In article <1990Jun29.175209.16251 at watdragon.waterloo.edu>, tbray at watsol.waterloo.edu (Tim Bray) writes:
> Am porting a big application to a decsystem 3100 running ultrix V2.something;
> the cc compiler complains about the following things:
> 3. Bitwise OR of enums (enum {e1, e2} foo; int set; set = e1 | e2;)
> 4. Bitwise AND of enums (enum {e1, e2} foo; int set; set = e1 & e2;)

You're absolutely right that in ANSI C an enumeration constant behaves
in an arithmetic expression as a constant of type 'int'.  On the other
hand, a compiler which doesn't like "void *" isn't an ANSI C compiler.
Some pre-ANSI compilers try to treat "enum" as a separate type; it's a
pity they only did a half-hearted job.

You should be able to get the effect you want by writing

    set = (int)e1 | (int)e2;
    set = (int)e1 & (int)e2;

I'm puzzled, though.  If you take the code fragments shown literally,

    enum {e1, e2} foo; int set; set = e1 | e2;	=> set == 1
    enum {e1, e2} foo; int set; set = e1 & e2;	=> set == 0

It's not clear to me why the variable is called "set"; certainly it
doesn't represent a *set* of enum values.  Surely the reason for
using an 'enum' type like this is that you don't *care* what numbers
the compiler assigns to the identifiers; if you want to do bitwise
operations on them, it's less confusing to your human readers to use
#defines or const ints (or at the very least to make the values
explicit in the enum definition: enum {e1 = 0, e2 = 1};).

-- 
"private morality" is an oxymoron, like "peaceful war".