Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!rphroy!caen!spool.mu.edu!uwm.edu!lll-winken!aunro!alberta!brazeau.ucs.ualberta.ca!unixg.ubc.ca!rabson From: rabson@physics.ubc.ca (David Rabson) Newsgroups: comp.std.c Subject: call to revolt Message-ID: Date: 25 Jun 91 16:43:40 GMT Sender: news@unixg.ubc.ca (Usenet News Maintenance) Organization: University of British Columbia, Vancouver, B.C., Canada Lines: 30 Nntp-Posting-Host: physics.ubc.ca Ath: physics.ubc.ca!rabson Until now, I have been content to sit back and ignore the ansi standard for C. Trigraphs are amusing -- I'm almost surprised the IBM representatives on the committee didn't push for including computed gotos as well -- but most compilers turn them off. Eliminating the IDENTA/**/IDENTB concatenation mechanism from the preprocessor was stupid but not enough to make me post to this group. (I am aware of the argument that supports the action, tokenizing compilers, but I am not convinced by it). Outlawing lvalue casts, however, borders on fascism. I have yet to see a pre-ansi compiler that fails to treat properly void *thing; ((int *)thing)++; (or, if it doesn't know about voids, the same thing with char *thing). I realize that some machines might, in principle, have different alignments for different types of pointers. A void *, however, I thought, was guaranteed to obey the most restrictive alignment and hence be castable to any other pointer. I hereby invite the black-shirts from the ansi camp to explain their prejudice against casting lvalues. The rest of us should stop sitting back and start fighting. If enough customers insist on casting lvalues and otherwising ignoring ansi's meddling in Kernighan's and Ritchie's work, vendors will create correct, rather than compliant, compilers. David Rabson Departments of Physics, University of British Columbia and McMaster University