Rex is editor of The Journal of C Language Translation, a quarterly publication aimed at implementors of C language translation tools. He also serves on the ANSI C committee X3J11, is the US international representative to ISO C, and is the convenor of the Numerical C Extensions Group. Rex can be contacted at 2051 Swans Neck Way, Reston, VA 22091, 703-860-0091, or via the Internet at rex@aussie.com.
We in the C industry are at a major milestone. We have our first language standard. We have many mainstream compiler vendors working hard to conform to that standard with quite a few of them probably already there. And we soon hope to have in operation a system for formal validation against that standard. Our industry is maturing. Some say that because of that, it is starting to die or at least fade. With everything supposedly nailed down by a formal definition, there's no room left for the entrepreneurial freedom that launched this language to such great heights. The media, of course, has lost quite a bit of its interest in this (dare I say) commonplace language and is instead focusing on the new darling, C++.
If you like to be "on the leading edge," okay. From my perspective, however, that's the last place I want to be if I have real work to do. With standardization comes stability. And while our very being is helped by change, it is just as much hindered by it. Creeping featurism we can do without, for the most part. Now that the hype seems to have gone from our beloved language we can get on with the job we were presumably hired to do. That is, deliver usable results using real people and a small, finite budget. And if we need to write portable code, at least we now have a much better chance of doing it than we ever had before.
At this point in C's life, it is worth looking back at how we got to where we are -- to what shaped the standard and why, and where we can and will go from here.
The first standard for C was that endorsed by the American National Standards Institute (ANSI) in December of 1989 (known formally as X3.159-1989). This standard was produced by the X3J11 committee under the auspices of the X3 Secretariat which, in turn, is managed by the Computer and Business Equipment Manufacturer's Association (CBEMA) in Washington, D.C. Strictly speaking, X3J11 is not an ANSI committee; however, it is generally known as the ANSI C committee.
How did X3J11 get started? For that we go back to early 1983 when Jim Brodie of Motorola was charged with implementing a C compiler. After having searched for a complete definition of the language, preprocessor, and library he concluded no such thing existed. What did exist was a book called The C Programming Language by Kernighan and Ritchie (now affectionately known as K&R); various papers published both within and outside AT&T's Bell Labs; and a myriad of compilers, most of which were either derived from, or tried to emulate, the Unix portable C compiler (pcc). If an implementor wanted to know what a C compiler was supposed to do in a particular situation, the answer was often "Why don't you run a test through pcc and see what it does?
Brodie reported to his boss that no complete description existed. His boss, who had previously been involved in language standards, suggested Brodie should make a standard because none currently existed. Brodie took the advice; after all, how long could it possibly take to pin down the few loose ends needed to make the definition really complete? (The answer was, about seven years.)
So Brodie became the convener of a proposed ANSI committee. His first big job was to write a project proposal outlining the goals and purposes of such a committee as well as the justifications and estimations of the resources it would need and where they would come from. This proposal was then submitted to SPARC (ANSI loves acronyms) for its consideration. Once they approved, the new committee was officially formed and named X3J11. (X3 is the ANSI subgroup that deals with computing standards, J is the language category within X3, and there were already ten other committees in existence. Other examples are X3J3 -- Fortran and X3J16 -- C++.)
The first official meeting was chaired by convener Brodie. A slate of officers was nominated and, eventually, elected. The original officers were: Chair, Brodie; Vice-Chair, Tom Plum, Secretary, P.J. Plauger; and Vocabulary Rep, Andy Johnson.
Larry Rosler volunteered to serve as editor of the draft standard. (Although the editor is not an officer, he obviously plays a very important role in the committee's work.) These people continue to serve in those capacities today except for Rosler who has been replaced by David Prosser. A Rationale editor (Randy Hudson) was added later, as was an International Representative (first Steve Hersee, then Plauger, and now myself).
The general impression users seem to have of standards is that they have been handed down from some divine authority that supposedly knows what is best for "mere mortals." In fact, X3J11 is made up of real people, many of whom actually program in C. If they are just "regular" C programmers, how do they get appointed to the high court of C? Well, they pretty much appoint themselves. Or at least their employers appoint them.
Anyone can attend and informally participate in an ANSI standards meeting even if they aren't registered members. However, to vote on issues of policy they must meet certain requirements. For example:
X3J11 has been dominated by implementors of C language translation tools. (This is not to suggest the resulting standard is somehow inadequate or biased, however. On the contrary, I think the standard is of very high quality.) Of course, each vendor also indirectly represented their own customer base. But what the vendor sees as being in his best interest may not be what his customer wants or needs. As C matures even further, it will be interesting to see if the composition of X3J11 membership changes. I suspect it will, but it's a slow process and few end users perceive the need to get involved at this level or can justify the investment in time and expense.
It is important to realize that X3J11 members must pay their own way in all standards-related activities and that membership is totally on a volunteer basis. Neither ANSI nor the X3 Secretariat provide any financial assistance. A gracious host must be found for each meeting. (Until recently, hosts had to duplicate and mail up to 200 sets of several hundred pages before and after each meeting.) ANSI's only revenue comes from committee membership fees and the sale of standards documents.
The aims are best stated by quoting the Rationale document that accompanies the C Standard:
The Committee's overall goal was to develop a clear, consistent, and unambiguous Standard for the C programming language which codifies the common, existing definition of C and which promotes the portability of user programs across C language environments.
The X3J11 charter clearly mandates the Committee to codify common existing practice. The Committee has held fast to precedent wherever this was clear and unambiguous. The vast majority of the language defined by the Standard is precisely the same as is defined in Appendix A of The C Programming Language by Brian Kernighan and Dennis Ritchie, and as is implemented in almost all C translators. (This document is hereinafter referred to as K&R.)
K&R is not the only source of existing practice. Much work has been done over the years to improve the C language by addressing its weaknesses. The Committee has formalized enhancements of proven value which have become part of the various dialects of C.
Existing practice, however, has not always been consistent. Various dialects of C have approached problems in different and sometimes diametrically opposed ways. This divergence has happened for several reasons. First, K&R, which has served as the language specification for almost all C translators, is imprecise in some areas (thereby allowing divergent interpretations), and it does not address some issues (such as a complete specification of a library) important for code portability. Second, as the language has matured over the years, various extensions have been added in different dialects to address limitations and weaknesses of the language; these extensions have not been consistent across dialects.
One of the Committee's goals was to consider such areas of divergence and to establish a set of clear, unambiguous rules consistent with the rest of the language. This effort included the consideration of extensions made in various C dialects, the specification of a complete set of required library functions, and the development of a complete, correct syntax for C.
The work of the Committee was in large part a balancing act. The Committee has tried to improve portability while retaining the definition of certain features of C as machine-dependent. It attempted to incorporate valuable new ideas without disrupting the basic structure and fabric of the language. It tried to develop a clear and consistent language without invalidating existing programs. All of the goals were important and each decision was weighed in the light of sometimes contradictory requirements in an attempt to reach a workable compromise.
In specifying a standard language, the Committee used several guiding principles, the most important of which are:
Because a standards committee tends to work in isolation during much of its deliberations, it was deemed important to get outside input once X3J11 had progressed far enough. As such, an unofficial public review period was announced and copies of the working draft were made available for purchase through CBEMA. Considerable time was then spent by X3J11 in analyzing the many criticisms and suggestions submitted.
The next stage was to have a formal public review. (From this point on, X3J11 required a two-thirds majority to change the draft instead of the previous simple majority.) In this case, the draft standard was issued for four months. All public comments had to be answered according to a detailed set of rules. In each instance where X3J11 decided to not adopt a suggestion it had to give some rationale as to why, and a dissatisfied public could appeal its treatment. Once all issues had been resolved, the cycle was repeated, but only for a two month period. After three public reviews, the draft standard had convergerd to its final form. This process continued until X3J11 converged to a standard that was acceptable to most (but not necessarily all) voting members and ANSI.
For all intents and purposes, the standard was complete by late 1988. However, sometime after the final public comment period ended, a letter from a member of the public was discovered by ANSI. It had been inadvertently mislaid. Despite the fact that the final draft included perhaps half of his suggestions already, the author of this letter wanted his pound of flesh. After X3J11 considered his comments (many of which requested support for real-time applications), they chose to not implement his remaining suggestions. Unhappy with that outcome, he chose the appeals route, which ultimately resulted in no further technical changes to the draft. After about a one year delay, an ANSI C standard was finally accepted late in 1989. For some, that might seem like the end of the line. However, it's really just the end of one cycle in a never-ending carousel ride. X3J11 not only has to interpret requests from the public but, eventually, must look at revising that standard.
Under ANSI rules, a standards committee must rule on interpretations of its standard. That is the main business of X3J11 at this time and for the foreseeable future. Because interpreting the standard requires much less time and effort than producing the initial standard, X3J11 went to a two day meeting schedule twice a year. However, as the workload increased, meetings have been extended to two-and-a-half days.
Examples of the interpretation requests processed thus far are:
An interpretation made by X3J11 does not have the weight of the standard and it can, in fact, be overturned by X3J11 or ANSI at some later date. However, it is expected that almost all interpretations will eventually find their way into a future revision of the standard. To help communicate interpretations to the outside world, X3J11 is in the process of publishing a technical bulletin containing all requests resolved to date.
In 1986 an ISO C standards committee was formed called SC22/WG14. At the same time, the draft ANSI standard was converging. However, due to input from US-based vendors wishing to sell compilers to non-English speaking countries, and from customers and vendors in those countries, considerable effort was put into enhancing the draft ANSI standard in two different directions: To better handle the western European single-byte characters containing diacritical marks (such as German's a and Spanish's n) and to better handle the multibyte character sets used in Asia.
Although this effort delayed the ANSI C standard for more than a year, it did pave the way for the ANSI standard to be adopted as the ISO standard without technical change. That is, except for reformatting changes, the ISO and ANSI C standards became equivalent. (The ISO standard is known as ISO/IEC 9899: 1990 (E).)
While X3J11 is busy handling interpretations, WG14 is blazing new trails on several fronts and is producing a normative addendum. The main parts of that addendum are:
Currently, WG14 meets twice a year for two or three days. Last November they met in Copenhagen. In May it was Tokyo and in December it will be Milan. Meetings are usually attended by representatives from four or five countries with each delegation having one to four members. No formal votes are held but, rather, decisions are made by consensus. Of course, getting work done at the ISO level is slower because delegates must get input from their national standards bodies, and the timing of X3J11 and WG14 can impact the ability of the US to quickly respond to proposals at the ISO level. Fortunately, considerable debate occurs by electronic mail both at the ISO and X3J11 level.
Numerous efforts are underway to extend the C language, its environment, or to define add-on libraries. Some of these are being pursued by groups affiliated with standards bodies while others are simply extensions to commercially available compilers. A few of the more notable ones are discussed here.
The Numerical C Extensions Group (NCEG) I convened this group in March 1989 as an ad hoc working group. Because ANSI C clearly was not going to address numerous issues of importance to the numerical community, I decided to try and coordinate the extensions that were already evolving in that direction. My intent was not to replace Fortran with a numerically extended C, however.
At the initial meeting of NCEG the following issues were identified as needing the most attention:
NCEG has met regularly since mid-1989, generally along with (in the two days that precede or follow) X3J11 meetings. In March of 1991, SPARC finally accepted NCEG's project proposal. NCEG has since become a working group within the ANSI umbrella and is now formally known as X3J11.1.
NCEG's mission is to produce a technical report, not a standard. Public comment drafts of parts of this report will likely become available early in 1992. The primary purpose of NCEG is to define approaches to solving numerical issues and to promote adoption of its solutions among the vendor community. This will hopefully play a major role in establishing prior art for future C standard revisions.
Others The ANSI committee X3H5 is defining a parallel processing model along with Fortran and C language bindings. Its first draft of a C binding appeared in December 1990 and is currently being revised based on input from numerous sources.
Various ISO committees are working on, or have completed, C language bindings in areas such as 2-D and 3-D GKS graphics.
AT&T has long had a research project on parallelism called "Concurrent C," while Thinking Machines has their language C*. There is also C++ and Stepstone's Objective C. The GNU C compiler from the Free Software Foundation has already played a significant role in making C available to numerous systems. That compiler also has numerous interesting experimental extensions. Another interesting project is being developed by the initial author of Turbo C. His language is tentatively called OPAL and is derived from C. Many other projects are underway, including C-cured, a version of C with a supposedly more rational way of declaring types.
When it was proposed that X3J11 take on the task of standardizing C++, it declined. Not only was this not within the original charter of X3J11, members spent more than six years working on C but they also had plenty of interpretation work to keep them busy. In any event, there were plenty of arguments as to why C++ was a different language despite its C roots. Eventually, a new committee (X3J16) was formed to work on C++, and within little more than a year, an ISO C++ working group was also formed.
There has been much discussion of X3J16's now well-known statement that C++ should be "as close as possible to ANSI C but no closer." In any event, there are moves afoot within X3J16 to keep C++ as upwards-compatible with C as possible and to diverge only when absolutely necessary. Such compatibility issues are being handled by X3J16's C Compatibility subgroup. Some of the main issues this group faces are:
Any vendor can claim conformance to Standard C, and many currently do. However, at the time of writing (May 1991) the C validation service within the US was not yet operational. The National Institute of Science and Technology (NIST, formerly the National Bureau of Standards) has, however, selected a validation suite from Perennial. This suite has been under technical review for several months now and is being revised to meet NIST requirements. It should be noted that NIST will validate against the FIPS C standard. (FIPS is an acronym for "Federal Information Processing Standard.") Currently, FIPS C is ANSI C with a few extra requirements.
The validation suite chosen by the British Standards Institute (BSI) and several other European standards bodies is from a different vendor, Plum Hall. Since BSI's conformance facility is operational, it has already begun issuing validation certificates for several compilers. BSI validates against ANSI/ISO C.
One interesting issue is that a conforming implementation must document what it does for all cases of implementation-defined behavior. Documentation cannot be automatically checked by a suite, so it remains to be seen just how this aspect will be handled.
Except for reformatting changes, the ISO and ANSI C standards are currently equivalent. As such, X3J11 and WG14 encourages all those concerned to talk about Standard C rather than ANSI or ISO C. We already talk of global economy and multinational companies abound. With the advent of real-time electronic communications the world is "shrinking." National boundaries are easily transcended and, for many issues, irrelevant. As such, it makes economic sense for us to work towards international standards rather than on isolated national fronts.
All indications are that future evolution of Standard C will be determined at the international level. National groups such as X3J11 will still continue to play a very important role and may even do development on behalf of WG14. However, the focus will be more and more on international standards. To that end, X3J11 is currently completing a letter ballot to withdraw X3.159-1989 and to replace it with ISO/IEC 9899: 1990 (E). That is, it is planning to make the ANSI C standard exactly the same as that from ISO, including the ISO format. This paves the way for X3J11 to officially track the work of WG14; as ISO C is revised, ANSI C can be revised in the same manner.
The technical report produced by NCEG will likely have some impact on future directions of C because many of the members of X3J11 are also active within X3J11.1.
As to C++, at this time I do not see it as the logical successor to C. For certain classes (no pun intended) of programs, C++ may indeed be more appropriate. However, C still has its own considerable niche. And with C leading the race to support multibyte and international software character sets via C's locales, I suspect C will be used in an even broader range of applications in the future.
To get further information about topics discussed in this article, contact the appropriate person or organization below:
The ANSI C Standard's official designation is ANSI X3.159-1989. The price of the standard is $65. Note that it is available in printed form only. To obtain a copy, contact:
American National Standards Institute Sales Department 11 West 42nd Street New York, NY 10036 212-642-4900; Fax: 212-398-0023 Sales Fax: 212-302-1286 Convenor of X3J11 (ANSI C) Jim Brodie Motorola Inc. Tempe, AZ 85284 602-897-4390 Internet: brodie@ssdt-tempe.sps.mot.com
If you would like to formally submit a request for interpretation of the C standard, contact:
Manager of Standards Processing X3 Secretariat, CBEMA 311 First Street N.W., Suite 500 Washington, DC 20001-2178 202-737-8888; Fax: 202-638-4922 Convenor of X3J11.1 (NCEG) Rex Jaeschke Journal of C Language Translation 2051 Swans Neck Way Reston, VA 22091 703-860-0091 Internet: rex@aussie.com Chairman of X3J16 (ANSI C++) Dmitry Lenkov Hewlett-Packard Company 19447 Pruneridge Avenue, MS 47LE Cupertino, CA 95014 408-447-5279 Internet: dmitry%hpda@hplabs.hp.com
The ISO C Standard's official designation is ISO/IEC 9899:1990 (E). Copies are available from ANSI in the US and from affiliated national standards organizations in other countries.
WG14 (US international rep.) Rex Jaeschke (see contact information) Vice-Chair of X3H5 (Parallel processing) Walter G. Rudd Department of Computer Science Oregon State University Corvallis, OR 97331-3902 503-737-5553; Fax: 503-737-3014 Internet: rudd@cs.orst.edu NIST-US validation issues and policy: National Institute of Science and Technology Software Standards Validation Group Gaithersburg, MD 20899 301-975-3247 US NIST-approved validation suite: Perennial 4699 Old Ironsides, Drive, Suite 210 Santa Clara, CA 95054 408-727-2255; Fax: 408-748-2909 Internet: uunet!peren!acvs BSI/European Validation Service British Standards Institution Quality Assurance (BSI QA) PO Box 375 Milton Keynes, MK14 6LL United Kingdom +44-0908-220908 Fax: +44-0908-226071 Internet: neil@bsiqa.uucp BSI/European-approved validation suite: Plum Hall Inc. 1 Spruce Avenue Cardiff, NJ 08232 609-927-3770; Fax: 609-653-1903 Internet: plum@plumhall.com
Copyright © 1991, Dr. Dobb's Journal