Evaluating ANSI C

[dmr at alice.UUCP]

Since the subject has come up, this is a good time to record my
thoughts on ANSI C and the work that X3J11 has done.  In brief,
I think the result is commendable.  I concur in the belief of those
who watch such things that X3J11 managed to improve on what they
started with, and that this is an unusual accomplishment for a large
committee that lasts for 5 years or so.  In particular, they successfully
resisted the usually inexorable pressure to add features and options.

The committee had certain explicit goals, among them to bring the
language specification up to date with reality, since much had changed
in the 10 years since the original definition; to add a very few things
deemed necessary (function prototypes); and to specify things more
completely than K&R did.  They also wanted to standardize the library,
something that has become important not only because the drift
in the System V vs. BSD worlds, but even more because of the
vastly increased use of C on non-Unix systems.

Perhaps as important as all the rest was a goal that was not stated
explicitly, namely to supply the stability, legitimacy and general
cachet that is possible only when an official committee mulls over
something for sufficient years, and complies with all the legalities
required to get the result accepted as an Official Standard by the
appropriate Official Bodies.  The need for this can be questioned,
but the fact that many people want it to happen, and that it tends to
occur regardless of desires, can't be denied.

I have only a few worries about the specification of the language.

First, the introduction of the new function declaration mechanism.
The new scheme is better than the old, but the change is going
to cause trouble, and the need to accommodate both ways confuses the
language specification and will confuse users.  I made my peace with
the change some years ago; it is better to do it than not.

Second, I don't think type qualifiers have been fully digested.
I never did object very strongly to volatile, even though I maintain
that it is not onerous to live without it.  The remaining qualifier,
const, suffers from tension between conflicting views of what
it is supposed to mean.  One possible view is that const things
are real constants.  If it prevailed, then one would expect that
things of type const could appear where constants are expected
(case labels and so forth).  Perhaps even the notion of pointer
to constant would become suspect.  This was not the view that the
committee eventually adopted, although (perhaps unconscious) sentiment
for it remains; instead, a more implementation-minded approach was
taken, namely that const means something that can be put in ROM
(hardware or write-protected memory).  Nevertheless, the tension
remains, and figured heavily in the committee's arguments over seemingly
unrelated things (including noalias).  Even now, questions of whether
a pointer to const can be assigned to an ordinary pointer, or
whether these two types are compatible (and when compatibility matters)
are lively issues.  It is clear that the rules on qualifiers are
to some extent artificial--they could be decided in several ways.
Good rules are not arbitrary, they are forced by the logic of the
design.

Some of the things that people are complaining about were completely
necessary, in particular the insistence that only a fixed set of
library routines is defined, that initial _ is reserved for the
implementation, and that all other names are reserved for the user.
It is just not possible to write a standard that permits the implementation
to intrude into the user's name space (by letting it define names
internal to its library that the user might use by accident), or
to give a defined, standard way for the user to replace system
routines.  The latter would constrain implementations too much.
At the same time, the consequences of such rules are misunderstood.
A program that calls "read" is not defined by the standard, but
I assure you that the supplier of your Unix system will arrange
that it works.

X3J11 did miss some opportunities.  Perhaps the most obvious lack
in the language is a scheme for variadic arrays.  However, the proposals
I have seen are awkward and don't fit smoothly, so it is not surprising
that nothing was done.

Another thing that must await the future is a genuine rethinking
of integer arithmetic, not just the fiddles that they did.

All in all, I think X3J11 did an excellent job.  When they began,
several years ago, I was somewhat apprehensive about what would result,
but also decided that I did not have the stamina to become involved in
their activities; I would have to trust their good sense.  I have never
regretted the decision, and I'm pleased with the outcome.


	Dennis Ritchie
	research!dmr
	dmr at research.att.com