Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: const, volatile, etc
Message-ID: <9269@smoke.BRL.MIL>
Date: 3 Jan 89 21:55:31 GMT
References: <715@auspex.UUCP> <225800102@uxe.cso.uiuc.edu> <475@aber-cs.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 55

In article <475@aber-cs.UUCP> pcg@cs.aber.ac.uk writes:
>I understand very well, as Doug Gwyn said, that X3J11 is nearly as
>political a body as a House public works committee (:->), ...

Note that I did NOT say that.  [Sleazy ploy #45.]

I said that I think that the "Common Extensions" section does not belong
in the Standard and exists there primarily for political reasons.  The
same, I think, is true of the deprecated [] parameter non-aliasing in
"Future Language Directions".  However, the ENFORCEABLE sections of the
Standard are remarkably clean, when one considers the variety of
technical and practical factors that had to be balanced; their
compromises are nearly always technically, not politically, motivated.
(Even the EXIT_* macros, originally driven by what many of us would
consider to have been a mistake in a certain existing implementation of
exit(), have intrinsic technical merit.)

>Does not dpANS C have the taste of an omnibus appropriations bill?  :->).

No, it does not.  Literally thousands of proposals for inclusion of a
variety of "nice features" were rejected.  Extensions beyond the base
documents were made only where there were perceived deficiencies and
viable solutions (usually based on existing practice) could be found.
The one major invention was the support for "internationalization";
this was mandated by ISO and is also commercially quite important.
(Such commercial concerns are valid, because they reflect genuine user
needs.)  I backed what I think was a technically superior solution to
the "large character set" issue, but at least I understand the several
arguments for all the proposed alternatives; since the decision was
made rationally after proper deliberation, I support the outcome even
though I "lost" on this issue.  In fact, in several committee
discussions of issues, I argued on multiple "sides" of the issues,
simply to make sure that all relevant factors were being considered in
arriving at each decision.  I maintain that this is the correct way
to make such decisions.

What ticked me off in the first place concerning Grandi's postings
is his presumption that he is fit to pass judgement on X3J11's work
when he is obviously unfamiliar with it.  I have no record of his
contributing to the public review process, which would have been the
appropriate channel for his suggestions about what "should" have been
done.  His description of X3J11's methods, goals, and results have in
most instances shown his ignorance of these matters.  In particular he
shows no sign of recognizing that the few valid "issues" he raises have
in fact been discussed in one form or another, and after discussion
and consideration of alternatives and trade-offs measured against the
goals of the Standard, the Committee deliberately decided on doing
things the way they are now specified (for good reasons of which Grandi
is apparently unaware).  Why does he continue to proclaim what is "wrong"
with the pANS without first having the relevant information at hand?
It sure is annoying.  (Aha! Maybe that's the reason.  How sick.)

If you want to see Grandi's qualifications for discussing what C should
be like, check out his rewrite of the "getchar loop" example in another
recent posting to see what he thinks C is like now!  Pretty amazing..