tbray@watsol.waterloo.edu (Tim Bray) (06/30/90)
Am porting a big application to a decsystem 3100 running ultrix V2.something;
the cc compiler complains about the following things:
1. The type 'void *' as a formal function parameter
2. The type 'void *' as a member of a union within a structure
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;)
5. enums as array indices (enum {e1, e2} foo; int x, y[3]; x = y[e1];)
These all seem like gross violations of both common sense and of the ANSI
C standard as I read it in K&R V2. In particular, there seems no excuse
for the refusal to deal with enums as stated.
Questions:
1. Am I insane, and the compiler correct?
2. Wil moving up to the most recent v3.whatever of ultrix correct this?
Apologies if this has been beaten to death here. If so, flames by mail
please.
Tim Bray, Open Text Systems, Waterloo, Ont. tbray@watsol.waterloo.edumeissner@osf.org (Michael Meissner) (06/30/90)
In article <1990Jun29.175209.16251@watdragon.waterloo.edu> tbray@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: | | 1. The type 'void *' as a formal function parameter | 2. The type 'void *' as a member of a union within a structure | 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;) | 5. enums as array indices (enum {e1, e2} foo; int x, y[3]; x = y[e1];) | | These all seem like gross violations of both common sense and of the ANSI | C standard as I read it in K&R V2. In particular, there seems no excuse | for the refusal to deal with enums as stated. | | Questions: | | 1. Am I insane, and the compiler correct? | 2. Wil moving up to the most recent v3.whatever of ultrix correct this? | | Apologies if this has been beaten to death here. If so, flames by mail | please. The Ultrix based MIPS compilers are not completely ANSI. Revision 1.31 in particular did not like void *. My spies tell me, revision 2.00 of the compiler suite will fix these problems, but I suspect the compiler has not been released in the V3 world, and is waiting for V4. With regard to enums, disallowing enums in normal integer operations without a cast was standard PCC (aka most UNIX systems) behavior. Both the relaxation of enums to be plain ints, and void * are features added in the ANSI standard, so older compilers may not yet support these features. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Do apple growers tell their kids money doesn't grow on bushes?
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (06/30/90)
In article <1990Jun29.175209.16251@watdragon.waterloo.edu>, tbray@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".
henry@zoo.toronto.edu (Henry Spencer) (07/01/90)
In article <1990Jun29.175209.16251@watdragon.waterloo.edu> tbray@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... >These all seem like gross violations of both common sense and of the ANSI >C standard as I read it in K&R V2... In general, it is unwise to assume that existing compilers conform to ANSI C. Many of them don't try, and some that try don't succeed. -- "Either NFS must be scrapped or NFS | Henry Spencer at U of Toronto Zoology must be changed." -John K. Ousterhout | henry@zoo.toronto.edu utzoo!henry