Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: (So-Called) ANSI C
Message-ID: <6931@brl-smoke.ARPA>
Date: 6 Jan 88 02:11:33 GMT
References: <4668@pyr.gatech.EDU> <495@xyzzy.UUCP> <9930@mimsy.UUCP> <228@unicom.UUCP> <510@xyzzy.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 35

In article <510@xyzzy.UUCP> throopw@xyzzy.UUCP (Wayne A. Throop) writes:
>Those two poinhts out of the way, it is my personal opinion that dpANS
>X3J11 innovates far, far to much, and is a little too eager to "clean
>up" some things in ways that don't really improve their cleanliness.
>But on the other hand, I don't expect these flaws I perceive will be
>fatal to the standard, and on balance, dpANS X3J11 is "still C", so to
>speak.

I doubt that there is any sane, qualified individual who is 100% happy
with every part of the proposed ANSI C standard.  Unfortunately, the
things that people don't agree with vary radically from person to
person.  The goal of the committee/negotiation/compromise/consensus
process is to end up with a total package that, on balance, is
considered "good enough" by a sufficient number of those involved.
I think the next draft comes quite close to this goal, and would urge
everyone to keep in mind that there is no way the final standard will
have precisely their favorite set of features and nothing else.  At
least X3J11 has been fairly successful at avoiding the "everything
including the kitchen sink" syndrome that often besets standardization
and design efforts.

Even though there are things that I, too, would like different in the
proposed standard, I believe that it is much more important to have a
timely "good enough" standard than to waste time trying to achieve the
impossible "universally ideal" standard.  To me, "good enough" requires
that everything that reasonably can be, should be specified "tightly".
Early drafts of the proposed IEEE Std 1003.1, for example, were way too
"loose", in an attempt to "bless" the widest possible range of existing
implementations, rather than guaranteeing the application programmer
crisp, useful, portable behavior of the standard system interface.
Recently this has been somewhat tightened up, but apparently the NBS
thinks it needs to be even tighter for their POSIX FIPS.  The ANSI C
committee, in collaboration with interested international groups,
appears to have avoided that particular trap: the proposed C standard
is nearly as tightly specified as portability permits.