Language Standards

I l @ ve RuBoard

Currently, many C implementations are available. Ideally, when you write a C program, it should work the same on any implementation, providing it doesn't use machine-specific programming. For this to be true in practice, different implementations need to conform to a recognized standard.

At first, there was no official standard for C. Instead, the first edition of The C Programming Language by Brian Kernighan and Dennis Ritchie (1978) became the accepted standard, usually referred to as K&R C or classic C . In particular, the "C Reference Manual" in the book's appendix acted as the guide to C implementors. Compilers, for example, would claim to offer a full K&R implementation. However, although this appendix defined the C language, it did not define the C library. More than most languages, C depends on its library, so there is need for a library standard, too. In the absence of any official standard, the library supplied with the UNIX implementation became a de facto standard.

The ANSI C Standard

As C evolved and became more widely used on a greater variety of systems, the C community realized it needed a more comprehensive, up-to-date, and rigorous standard. To meet this need, the American National Standards Institute (ANSI) established a committee (X3J11) in 1983 to develop a new standard, which was adopted formally in 1989. This new standard (ANSI C) defines both the language and a standard C library. The International Standards Organization adopted a C standard (ISO C) in 1990. ISO C and ANSI C are essentially the same standard. The final version of the standard is often referred to as C90 .

The committee had several guiding principles. Perhaps the most interesting was this: Keep the spirit of C. The committee listed the following ideas as expressing part of that spirit:

 Trust the programmer. Don't prevent the programmer from doing what needs to be done. Keep the language small and simple. Provide only one way to do an operation. Make it fast, even if it is not guaranteed to be portable.

By the last point, the committee meant that an implementation should define a particular operation in terms of what works best for the target computer, instead of trying to impose an abstract, uniform definition. You'll encounter examples of this philosophy as you learn the language.

For the most part, C compiler vendors for microcomputers, such as IBM PCs and Macintoshes, took an evolutionary approach to converting to ANSI C, adding features from the early ANSI drafts as it became apparent those features would be in the final version. UNIX systems, on the other hand, stuck with K&R C until the ANSI standard became official. ANSI C, therefore, came to the UNIX world later ”but fully implemented ”than to the PC world. The public domain gcc UNIX C compiler, however, switched to ANSI C earlier than the standard cc UNIX C compiler, so if your UNIX system has a K&R cc compiler, check to see whether someone has installed an ANSI C gcc version.

This book follows the ANSI C standard. Often, ANSI C and K&R C are much the same. However, ANSI C does support some extensions and changes. We'll mention many of them when appropriate. Because you may find yourself using implementations that lack some ANSI C features, we'll point out where there are conflicts.

The C9X Committee

In 1994, work began on revising the standard. The committee working on the revision is known as the C9X committee. The committee endorsed the original principles of the C90 standard, including keeping the language small and simple. Therefore, the intent is not to add new features to the language, except as needed to meet the new goals. One of the main motivations is to support international programming, such as providing ways to deal with international character sets. A second goal is to "codify existing practice to address evident deficiencies." For example, commonly available computers have moved from 8-bit processors to 16-bit processors to 32-bit processors and are moving to 64-bit processors, and C needs to respond to the increased capacities of such processors. By codifying existing practice, the committee means that it intends to meet recognized deficiencies by incorporating solutions already developed by the programming community instead of inventing solutions from scratch. This way, the committee can benefit from the experiences of those who deal with these problems in real life.

These two goals, internationalization and correcting deficiencies, are the main change-oriented goals. The remaining new goals are more conservative in nature, for example, minimizing incompatibilities with C90 and with C++ and keeping the language conceptually simple. In the committee's words, " the committee is content to let C++ be the big and ambitious language."

The upshot is that C9X changes will be fairly minor and that C will remain the lean, clean, efficient language. This book points out some of the proposed C9X changes when relevant. Also, Appendix H, "The C9X Committee," summarizes many of the C9X features.

I l @ ve RuBoard