At the 2007 meeting of WG14, the ISO working group for the C programming language, there was a general consensus that the committee should start working on the next revision of the C standard.

The committee saw there was much happening that can or does influence C directly. Examples are the evolution of C-like programming languages (C#, Java and C++), multi-thread programming, the rising threat to Internet security, the increased awareness of programming language vulnerabilities, and emphasis on safety-critical systems, to name just a few.

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:

1. Existing code is important; existing implementations are not. A For example, there is a large body of C code of considerable commercial value. Every attempt has been made to ensure that the bulk of this code will be acceptable to any implementation conforming to the standard. The committee did not want to force most programmers to modify their C programs just to have them accepted by a conforming translator.

On the other hand, no single implementation was held up as the exemplar by which to define C; it is assumed that all existing implementations must change somewhat to conform to the standard.

2. C code can be portable. Although the C language was originally born with the Unix operating system on the DEC PDP-11, it has since been implemented on a wide variety of computers and operating systems. The committee has attempted to specify the language and the library to be as widely implementable as possible, while recognizing that a system must meet certain minimum criteria to be considered a viable host or target for the language.

3. C code can be non-portable. Although it strove to give programmers the opportunity to write truly portable programs, the committee did not want to force programmers into writing portably in order to preclude the use of C as a “high-level assembler.” The ability to write machine-specific code is one of the strengths of C. It is this principle that largely motivates drawing the distinction between a strictly conforming program and a conforming program.

4. Avoid “quiet changes.” Any change to widespread practices that alters the meaning of existing code causes problems. Changes that cause code to be so ill-formed as to require diagnostic messages are at least easy to detect. As much as seemed possible, the committee has avoided changes that quietly alter one valid program to another with different semantics, which cause a program to work differently without notice.

5. A standard is a treaty between implementer and programmer. Some numerical limits have been added to the standard to give both implementers and programmers a better understanding of what must be provided by an implementation, of what can be expected and depended upon to exist. These limits are presented as minimum maxima (for example, lower limits placed on the values of upper limits specified by an implementation) with the understanding that any implementer is at liberty to provide higher limits than the standard mandates. Any program that takes advantage of these more-tolerant limits is not strictly conforming, however, since other implementations are at liberty to enforce the mandated limits.

6. Keep the spirit of C. There are many facets of the spirit of C, but the essence is a community sentiment of the underlying principles upon which the C language is based. For the C11 revision, there is consensus to add a new facet—f—to the original list of facets. The new spirit of C can be summarized in phrases like:

(a) Trust the programmer.
(b) Don’t prevent the programmer from doing what needs to be done. (c) Keep the language small and simple.
(d) Provide only one way to do an operation.
(e) Make it fast, even if it is not guaranteed to be portable.
(f) Make support for safety and security demonstrable.

(e) needs a little explanation. The potential for efficient code generation is one of the most important strengths of C. To help ensure that no code explosion occurs for what appears to be a very simple operation, many operations are defined to be how the target machine’s hardware does it rather than by a general abstract rule. An example of this willingness to live with what the machine does can be seen in the rules that govern the widening of char objects for use in expressions: whether the values of char objects widen to signed or unsigned quantities typically depends on which byte operation is more efficient on the target machine.

One of the goals of the committee was to avoid interfering with the ability of translators to generate compact, efficient code. In several cases, the committee has introduced features to improve the possible efficiency of the generated code; for instance, floating point operations may be performed in single precision if both operands are float rather than double.

Additional principles include:

7. Support internationalization. During the initial standardization process, support for internationalization was something of an afterthought. Now that internationalization has proved to be an important topic, it should have equal visibility with other topics.

8. Codify existing practices to address evident deficiencies. Only those concepts that have some prior art should be accepted. Unless some proposed new feature addresses an evident deficiency that is actually felt by more than a few C programmers, no new inventions should be entertained.

9. Minimize incompatibilities with C90 (ISO/IEC 9899:1990). It should be possible for existing C implementations to gradually migrate to future conformance, rather than requiring a replacement of the environment. It should also be possible for the vast majority of existing conforming C programs to run unchanged.

10. Minimize incompatibilities with C++. The committee endorses the principle of maintaining the largest common subset clearly and from the outset. Such a principle should satisfy the requirement to maximize overlap of the languages while maintaining a distinction between them and allowing them to evolve separately.

Regarding our relationship with C++, the committee is content to let C++ be the “big” and ambitious language. While some features of C++ may well be embraced, it is not the committee’s intention that C becomes C++; however, in areas such as the memory model, C will do whatever it takes to be compatible with C++.

11. Maintain conceptual simplicity. The committee prefers an economy of concepts that do the job. Members should identify the issues and prescribe the minimal amount of machinery that will solve them. The committee recognizes the importance of being able to describe and teach new concepts in a straightforward and concise manner.

Additional observations were added after the 2007 meeting:

12. “Trust the programmer,” as a goal, is outdated with respect to the security and safety programming communities. While it should not be totally disregarded as a facet of the spirit of C, the C11 version of the C standard should take into account that programmers need the ability to check their work.

13. Unlike for C99, the consensus at the London meeting was that there should be no invention, without exception. Only those features that have a history and are in common use by a commercial implementation should be considered. Also there must be care to standardize these features in a way that would make the standard and the commercial implementation compatible.

14. Migration of an existing codebase is an issue. The ability to mix and match C89-, C99- and C11-based code is a feature that should be considered for each proposal.