Previous | Table of Contents | Next |
By 1982, it was clear that C needed formal standardization. The best approximation to a standard, the first edition of K&R, no longer described the language in actual use; in particular, it mentioned neither the void nor enum types. Although it foreshadowed the newer approach to structures, only after it was published did the language support assigning them, passing them to and from functions, and associating the names of members firmly with the structure or union containing them. Although compilers distributed by AT&T incorporated these changes, and most of the purveyors of compilers not based on pcc quickly picked them up, there remained no complete, authoritative description of the language.
The first edition of K&R was also insufficiently precise on many details of the language, and it became increasingly impractical to regard pcc as a reference compiler; it did not perfectly embody even the language described by K&R, let alone subsequent extensions. Finally, the incipient use of C in projects subject to commercial and government contract meant that the imprimatur of an official standard was important. Thus (at the urging of M. D. McIlroy), ANSI established the X3J11 committee under the direction of CBEMA in the summer of 1983 with the goal of producing a C standard. X3J11 produced its report (ANSI, 1989) at the end of 1989, and subsequently, this standard was accepted by ISO as ISO/IEC 98991990.
From the beginning, the X3J11 committee took a cautious, conservative view of language extensions. Much to my satisfaction, they took their goal seriously: to develop a clear, consistent, and unambiguous standard for the C programming language that codifies the common, existing definition of C and that promotes the portability of user programs across C language environments (ANSI, 1989). The committee realized that mere promulgation of a standard does not make the world change.
X3J11 introduced only one genuinely important change to the language itself: It incorporated the types of formal arguments in the type signature of a function, using syntax borrowed from C++ (Stroustrup, 1986). In the old style, external functions were declared like this:
double sin();
which says only that sin is a function returning a double (that is, doubleprecision floatingpoint) value. In the new style, this better rendered
double sin(double);
to make the argument type explicit and thus encourage better type checking and appropriate conversion. Even this addition, although it produced a noticeably better language, caused difficulties. The committee justifiably felt that simply outlawing old-style function definitions and declarations was not feasible, yet also agreed that the new forms were better. The inevitable compromise was as good as it could have been, although the language definition is complicated by permitting both forms, and writers of portable software must contend with compilers not yet brought up to standard.
X3J11 also introduced a host of smaller additions and adjustmentsfor example, the type qualifiers const and volatile and slightly different type promotion rules. Nevertheless, the standardization process did not change the character of the language. In particular, the C standard did not attempt to specify formally the language semantics, so there can be dispute over fine points; nevertheless, it successfully accounted for changes in usage since the original description and is sufficiently precise to base implementations on it.
Thus the core C language escaped nearly unscathed from the standardization process, and the standard emerged more as a better, careful codification than a new invention. More important changes took place in the languages surroundings: the preprocessor and the library. The preprocessor performs macro substitution using conventions distinct from the rest of the language. Its interaction with the compiler had never been well described, and X3J11 attempted to remedy the situation. The result is noticeably better than the explanation in the first edition of K&R; besides being more comprehensive, it provides operations, such as token concatenation, previously available only by accidents of implementation.
X3J11 correctly believed that a full and careful description of a standard C library was as important as its work on the language itself. The C language itself does not provide for input/output or any other interaction with the outside world and thus depends on a set of standard procedures. At the time of publication of K&R, C was thought of mainly as the system programming language of UNIX; although we provided examples of library routines intended to be readily transportable to other operating systems, underlying support from UNIX was implicitly understood. Thus, the X3J11 committee spent much of its time designing and documenting a set of library routines required to be available in all conforming implementations.
By the rules of the standards process, the current activity of the X3J11 committee is confined to issuing interpretations on the existing standard. However, an informal group originally convened by Rex Jaeschke as NCEG (Numerical C Extensions Group) has been officially accepted as subgroup X3J11.1, and they continue to consider extensions to C. As the name implies, many of these possible extensions are intended to make the language more suitable for numerical use: for example, adding multidimensional arrays whose bounds are dynamically determined, incorporating facilities for dealing with IEEE arithmetic, and making the language more effective on machines with vector or other advanced architectural features. Not all the possible extensions are specifically numerical; they include a notation for structure literals.
Previous | Table of Contents | Next |