Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.std.c
Subject: Re: call to revolt
Message-ID: <6572@goanna.cs.rmit.oz.au>
Date: 30 Jun 91 11:21:18 GMT
References: <782@taumet.com> <998@baby.and.nl> <1015@baby.and.nl>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 31

In article <1015@baby.and.nl>, jos@and.nl (J. Horsmeier) writes:
> Hi, please let's stop this silly discussion.
> Once and for all, I am *not* complaining.
                    ^^^^^^^^^^^^^^^^^^^^^^

> Ripping non-portable `features' out of a language is not doing any
> good to that language.  ...
> But, for all sake, don't amputate them from a language
> (which was the original assumption).

If this isn't a complaint, it will do until the real thing comes along.
The thing which some posters seem to have difficulty grasping is that
X3J11 DID NOT RIP L-VALUE CASTS OUT OF THE LANGUAGE.  You might as well
complain that they removed the `max' and `min' operators from the
language!  Fact:  there were a couple of compilers around that provided
infix operators /\ and \/.  I _loved_ those operators; even fixed one of
the compiler so they worked.  That was a non-portable feature in
*precisely* the same sense as L-value casts.  We're not talking here
about an operation which wasn't well defined (like right shift of signed
integers, or the rules for combining signed and unsigned), we're talking
about features which, although _some_ compilers had them, were NEVER
part of "Classic C".

I wish that /\ and \/ were in ANSI C, but I don't whine about X3J11
"ripping them out of the language", and although it is far less trivial
to reorganise code to do without /\ and \/ than to do without L-value
casts (which don't even let you abbreviate by more than a couple of
characters), I don't accuse X3J11 of "amputating" the wings on that pig.

-- 
I agree with Jim Giles about many of the deficiencies of present UNIX.