dmr@alice.UUCP (05/18/88)
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@research.att.com