Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!iWarp.intel.com!inews!hopi!bhoughto From: bhoughto@hopi.intel.com (Blair P. Houghton) Newsgroups: comp.std.c Subject: Re: call to revolt Message-ID: <4856@inews.intel.com> Date: 25 Jun 91 20:07:11 GMT References: <1991Jun25.181916.26586@zoo.toronto.edu> Sender: news@inews.intel.com Organization: Intel Corp, Chandler, AZ Lines: 36 In article <1991Jun25.181916.26586@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article rabson@physics.ubc.ca (David Rabson) writes: >>Outlawing lvalue casts, however, borders on fascism. >> void *thing; >> ((int *)thing)++; And then I suppose the next line is ((double *)thing)++; >Remember that `void *' and `int *' need not even be the >same size, much less have the same representation. A cast >is a conversion operation, not a "view these bits >differently" operation. (See K&R1 page 42.) Much less the same location; after the cast the value may be sitting in an accumulator, or in the phase space on the wiring at 14.5 picoseconds antecedent to the accumulator (Cray was a genius, kids, not just another hacker :-)), but not necessarily anywhere near the storage for `thing'. >Please cite K&R chapter and verse for thinking that casts are lvalues. They certainly aren't addressable. >>The rest of us should stop sitting back and start fighting. If enough >>customers insist on casting lvalues and otherwising ignoring ansi's They'll be left behind. I've seen other standards that have had _real_ problems in them, and nobody bothers with them any more. ANSI X3.159-1989, on the other hand, is pretty solid, almost impervious. --Blair "Write when you find a bug."