README -4
README
-4 This book probably needs one of these.
Commentary
While it was written sequentially, starting at sentence 1 and ending with sentence 2043, readers are unlikely
to read it in this way.
At some point you ought to read all of sentence 0 (the introduction).
The conventions used in this book are discussed on the following pages.
There are several ways in which you might approach the material in this book, including the following:
• You have read one or more sentences from the C Standard and want to learn more about them. In this
case simply locate the appropriate C sentence in this book, read the associated commentary, and follow
any applicable references.
• You want to learn about a particular topic. This pdf is fully searchable. Ok, the search options are
not as ﬂexible as those available in a search engine. The plan is to eventually produce separate html
versions of each C sentence and its associated commentary. For the time being only the pdf is available.
For anybody planning to print a (double sided) paper copy. Using 80g/m2 stock produces a stack of paper
that is 9.2cm (3.6inches) deep.
June 24, 2009 v 1.2

-3 Preface
Preface
The New C Standard: An economic and cultural commentary -3
Commentary
This book contains a detailed analysis of the International Standard for the C language,-3.1 excluding the
library from a number of perspectives. The organization of the material is unusual in that it is based on
the actual text of the published C Standard. The unit of discussion is the individual sentences from the C
Standard (2043 of them).
Readers are assumed to have more than a passing familiarity with C.
C90
My involvement with C started in 1988 with the implementation of a C to Pascal translator (written in Pascal).
In 1991 my company was one of the three companies that were joint ﬁrst, in the world, in having their
C compiler formally validated. My involvement with the world of international standards started in 1988
when I represented the UK at a WG14 meeting in Seattle. I continued to head the UK delegation at WG14
meetings for another six years before taking more of a back seat role.
C++
Having never worked on a C++ compiler or spent a signiﬁcant amount of time studying C++ my view on this
language has to be considered as a C only one. While I am a member of the UK C++ panel I rarely attend
meetings and have only been to one ISO C++ Standard meeting.
There is a close association between C and C++ and the aim of this subsection is the same as the C90 one:
document the differences.
Other Languages
The choice of other languages to discuss has been driven by those languages in common use today (e.g.,
Java), languages whose behavior for particular constructs is very different from C (e.g., Perl or APL), and
languages that might be said to have been an early inﬂuence on the design of C (mostly BCPL and Algol 68).
The discussion in these subsections is also likely to have been inﬂuenced by my own knowledge and
biases. Writing a compiler for a language is the only way to get to know it in depth and while I have used
many other languages I can only claim to have expertise in a few of them. Prior to working with C I had
worked on compilers and source code analyzers for Algol 60, Coral 66, Snobol 4, CHILL, and Pascal. All of
these languages might be labeled as imperative 3GLs. Since starting work with C the only other languages I
have been involved in at the professional compiler writer level are Cobol and SQL.
Common Implementations
The perceived needs of customers drive translator and processor vendors to design and produce products.
The two perennial needs of performance and compatibility with existing practice often result in vendors
making design choices that signiﬁcantly affect how developers interact with their products. The common
implementation subsections discuss some the important interactions, primarily by looking at existing imple-
mentations and at times research projects (although it needs to be remembered that many of research ideas
never make it into commercial products).
I have written code generators for Intel 8086, Motorola 68000, Versal (very similar to the Zilog Z80),
Concurrent 3200, Sun SPARC, Motorola 88000, and a variety of virtual machines. In their day these
processors have been incorporated in minicomputers or desktop machines. The main hole in my cv. is a
complete lack of experience in generating code for DSPs and vector processors (i.e., the discussion is based
purely on book learning in these cases).
-3.1 The document analysed is actually WG14/N1256 (available for public download from the WG14 web site www.open-std.org/
jtc1/sc22/wg14/). This document consists of the 1999 version of the ISO C Standard with the edits from TC1, TC2 and TC3 applied
to it (plus a few typos corrected).
v 1.2 June 24, 2009

Preface -3
Coding Guidelines
Writing coding guidelines is a very common activity. Whether these guidelines provide any beneﬁt other
than satisfying the itch that caused their author to write them is debatable. My own itch scratchings are based
on having made a living, since 1991, selling tools that provide information to developers about possible
problems in C source code.
The prime motivating factor for these coding guidelines subsections is money (other coding guideline
documents often use technical considerations to label particular coding constructs or practices as good or
bad). The speciﬁc monetary aspect of software of interest to me is reducing the cost of source code ownership.
Given that most of this cost is the salary of the people employed to work on it, the performance characteristics
of human information processing is the prime consideration.
Software developer interaction with source code occurs over a variety of timescales. My own interests and
professional experience primarily deals with interactions whose timescale are measured in seconds. For this
reason these coding guidelines discuss issues that are of importance over this timescale. While interactions
that occur over longer timescales (e.g., interpersonal interaction) are important, they are not the primary focus
of these coding guideline subsections. The study of human information processing, within the timescale of
interest, largely falls within the ﬁeld of cognitive psychology and an attempt has been made to underpin the
discussion with the results of studies performed by researchers in this ﬁeld.
The study of software engineering has yet to outgrow the mathematical roots from which it originated.
Belief in the mathematical approach has resulted in a research culture where performing experiments is
considered to be unimportant and every attempt is made to remove human characteristics from consideration.
Industry’s insatiable demand for software developers has helped maintain the academic status quo by
attracting talented individuals with the appropriate skills away from academia. The end result is that most of
the existing academic software engineering research is of low quality and suffers from the problem of being
carried out by people who don’t have the ability to be mathematicians or the common sense to be practicing
software engineers. For this reason the results of this research have generally been ignored.
Existing models of human cognitive processes provide a general framework against which ideas about the
mental processes involved in source code comprehension can be tested. However, these cognitive models
are not yet sophisticated enough (and the necessary empirical software engineering data is not available) to
enable optimal software strategies to be calculated. The general principles driving the discussion that occurs
in these coding guidelines subsections include:
1. the more practice people have performing some activity the better they become at performing it.
Our attitude towards what we listen to is determined by our habits. We expect things to be said in the
Aristotle Meta-
ways in which we are accustomed to talk ourselves: things that are said some other way do not seem the physics book II
same to all but seem rather incomprehensible. . . . Thus, one needs already to have been educated in the
way to approach each subject.
Many of the activities performed during source code comprehension (e.g., reasoning about sequences
of events and reading) not only occur in the everyday life of software developers but are likely to have
been performed signiﬁcantly more often in an everyday context. Using existing practice provides a
beneﬁt purely because it is existing practice. For a change to existing practice to be worthwhile the
total beneﬁt has to be greater than the total cost (which needs to include relearning costs),
2. when performing a task people make implicitly cost/beneﬁt trade-offs. One reason people make
mistakes is because they are not willing to pay a cost to obtain more accurate information than they
already have (e.g., relying on information available in their head rather expending effort searching for
it in the real world). While it might be possible to motivate people to make them more willing pay a
greater cost for less beneﬁt the underlying trade-off behavior remains the same,
3. people’s information processing abilities are relatively limited and cannot physically be increased (this
is not to say that the cognitive strategies used cannot be improved to make the most efﬁcient use of
June 24, 2009 v 1.2

-3 Preface
these resources). In many ways the economics of software development is the economics of human
attention.
Usage
Software engineering is an experimental, not a theoretical discipline, and an attempt has been made to base
the analysis of C on what software developers and language translators do in practice.
The source code for many of the tools used to extract the information needed to create these ﬁgures and
tables is available for download from the book’s web site.
Measuring the characteristics of software that change over many releases (software evolution) is a relatively
new research topic. Software evolution is discussed in a few sentences and any future major revision ought
to cover this important topic in substantially more detail.
Table -3.1: Occurrences of various constructs in this book.
Quantity Kind of information
2,043 C language sentences
1,525 Citations to published books and papers
229 Tables
208 Figures
1,721 Unique cross-reference entries
v 1.2 June 24, 2009

Acknowledgments -2
Acknowledgments
-2 The New C Standard: An economic and cultural commentary
Commentary
Thanks to Sean Corﬁeld (corfield.org) and later Gavin Halliday for many interesting discussions on
implementing C90. Also thanks to Clive Feather, the UK C panel, the members of WG14, and my consulting
customers who were the source of many insights.
Clive Feather reviewed most of the material in this book. Fred Tydeman reviewed the ﬂoating-point
material in all subsections. Frank Griswold provided a detailed review of over half of the C++ material.
Stephen Parker reviewed a very early draft of some of the coding guidelines. Ken Odgers converted the C99
text from troff format to XML.
Most of the work on the scripts and style sheets/macros used for the layout was done by Vic Kirk. Thanks
to the authors of TeXlive, grap, pic, graphviz, and a variety of ’nix based tools.
Marilyn Rash (rrocean@shore.net) copyedited 75% of the material.
Thanks to the librarians of Reading, Surrey, and Warwick Universities for providing access to their
collections of Journals. Thanks to all those people who made their papers available online (found via
Altavista and later Google and Citeseer).
Post version 1.0
Thanks to the following people for reporting problems in previous versions: Steve Bragg, David Bremner,
Giacomo A. Catenazzi, Eric J. Christeson, Cliff Click, Pascal Cuoq, Harald van Dijk, Martin Elwin, Luca
Forlizzi, Rodolfo Federico Gamarra, Jeffrey Haemer, Stephen Hite, Jon Jagger, Chris Johansen, Kent
Karlsson, Philipp Klaus Krause, Chris Lattner, Jonathan Lefﬂer, Kein-Hong Man, Riesch Nicolas, Arthur
O’Dwyer, Casey Peel, Jesse Perry, Tom Plum, David Poirier, Arvin Schnell, Ralph Siemsen, Clive Taylor,
Pavel Vozenilek and Gregory Warnes.
June 24, 2009 v 1.2

-1 Conventions
Conventions
information This is a sentence from WG14/N1124, the number on the inside margin (it would be in a bound book) is the -1
deﬁned here
sentence number and this wording has been deletedadded from/to the wording in C99 by the response to a
defect report.
Commentary
This is some insightful commentary on the above sentence. We might also say something relating to this
another issue in another sentence (see sentence number and reference heading in the outside margin—it would be in
sentence
a bound book).
Terms and phrases, such as blah, visually appear as just demonstrated.
Rationale
This is a quote from the Rationale document produced by the C Committee to put a thoughtful spin on the
wording in the standard.
Various fonts and font-styles are used to denote source code examples (e.g., a+b*c), keywords (e.g., else),
syntax terminals (e.g., integer-constant), complete or partial ﬁle names (e.g., .obj), programs (e.g.,
make), program options (e.g., -xs1234), C Standard identiﬁers (e.g., wchar_t), library functions (e.g.,
malloc) and macros (e.g., offsetof).
The headers that appear indented to the left, displayed in a bold Roman font, appear in the C Standard
between the two C sentences that they appear between in this book.
C90
This section deals with the C90 version of the standard. Speciﬁcally, how it differs from the C99 version of
the above sentence. These sections only appear if there is a semantic difference (in some cases the words
may have changed slightly, leaving the meaning unchanged).
This is the text of a DR (defect report) submitted to the ISO C Standard committee.
DR #987
Response
The committee’s response to this DR is that this question is worth repeating at this point in the book.
This is where we point out what the difference, if any (note the change bar), and what the developer might
do, if anything, about it.
C++
This is a sentence from the C++ standard specifying behavior that is different from the above C99 sentence. The
1.1p1
1.1p1 in the outside margin is the clause and paragraph number of this quote in the C++ Standard.
This is where we point out what the difference is, and what the developer might do, if anything, about it. You
believed the hype that the two languages are compatible? Get real!
Other Languages
Developers are unlikely to spend their entire professional life using a single language. This section sometimes
gives a brief comparison between the C way of doing things and other languages.
We vote against the adoption of the proposed new COBOL standard because we have lost some of our source
Comment received
during balloting code and don’t know whether the requirements in the proposed new standard would invalidate this source.
Common Implementations
processors Discussion of how implementations handle the above sentence. For instance, only processors with 17 bit
17 bit
integers can implement this requirement fully (note the text in the outside column—ﬂush left or ﬂush right
to the edge of the page—providing a heading that can be referenced from elsewhere). gcc has extensions
v 1.2 June 24, 2009

Conventions -1
to support 16 bit processors in this area (the text in the outside margin is pushed towards the outside of the
page, indicating that this is where a particular issue is discussed; the text appearing in a smaller point size is
a reference to material appearing elsewhere {the number is the C sentence number}). translated
invalid program
This is a quote from the document referenced in the outside sidebar.
The New C Stan-
dard
Coding Guidelines
General musings on how developers use constructs associated with the above sentence. Some of these
sections recommend that a particular form of the construct described in the above sentence not be used.
Cg -1.1
Do it this way and save money.
Dev -1.1
A possible deviation from the guideline, for a described special case.
Rev -1.2
Something to look out for during a code review. Perhaps an issue that requires a trade off among
different issues, or that cannot be automated.
Example
An example, in source code of the above sentence.
The examples in this book are generally intended to illustrate some corner of the language. As a general
rule it is considered good practice for authors to give examples that readers should follow. Unless stated
otherwise, the examples in this book always break this rule.
1 struct {float mem;} main(void)
2 {
3 int blah; /* The /* form of commenting describes the C behavior */
4 // The // form of commenting describes the C++ behavior
5 }
Usage
A graph or table giving the number of occurrences (usually based on this book’s benchmark programs) of
the constructs discussed in the above C sentence.
June 24, 2009 v 1.2

1 Effort invested in producing the C Standard Introduction 0
Your author has found that a common complaint made about his discussion of C is that it centers on what
the standard says, not on how particular groups of developers use the language. No apology is made for this
outlook. There can be no widespread discussion about C until all the different groups of developers start
using consistent terminology, which might as well be that of the standard. While it is true that your author’s
involvement in the C Standards’ process and association with other like-minded people has resulted in a
strong interest in unusual cases that rarely, if ever, occur in practice, he promises to try to limit himself to
situations that occur in practice, or at least only use the more obscure cases when they help to illuminate the
meaning or intent of the C Standard.
No apologies are given for limiting the discussion of language extensions. If you want to learn the details
of speciﬁc extensions, read your vendor’s manuals.
Always remember the deﬁnitive deﬁnition is what the words in the C Standard say. In responding to defect
reports the C committee have at times used the phrase the intent of the Committee. This phrase has been 0 defect report
used when the wording in the standard is open to more than one possible interpretation and where committee
members can recall discussions (via submitted papers, committee minutes, or committee email) in which the
intent was expressed. The Committee has generally resisted suggestions to rewrite existing, unambiguous,
wording to reﬂect intent (when the wording has been found to specify different behavior than originally
intended).
As well as creating a standards document the C committee also produced a rationale. This rationale document
Rationale
provides background information on the thinking behind decisions made by the Committee.
Wording that appears within a sectioned area like this wording is a direct quote from the rationale (the
document used was WG14/N937, dated 17 March 2001).
No standard is perfect (even formally deﬁned languages contain mistakes and ambiguities[721] ). There is a
mechanism for clarifying the wording in ISO standards, defect reports (DRs as they are commonly called). 0 defect report
The text of C99 DRs are called out where applicable.
1 Effort invested in producing the C Standard
The ANSI Committee which produced C90, grew from 13 members at the inaugural meeting, in June 1983,
to around 200 members just prior to publication of the ﬁrst Standard. During the early years about 20 people
would attend meetings. There was a big increase in numbers once drafts started to be sent out for public
review and meeting attendance increased to 50 to 60 people. Meetings occurred four times a year for six
years and lasted a week (in the early years meetings did not always last a week). People probably had to put,
say, a week’s effort into reading papers and preparing their positions before a meeting. So in round numbers
let’s say:
(20 people × 1.3 weeks × 3 meetings × 1 years) +
(20 people × 1.7 weeks × 4 meetings × 2 years) +
(50 people × 2.0 weeks × 4 meetings × 3 years) ⇒ 1,540 person weeks (not quite 30 years)
What about the 140 people not included in this calculation— how much time did they invest? If they spent
just a week a year keeping up with the major issues, then we have 16 person years of effort. On top of this
we have the language users and implementors reviewing drafts that were made available for public review.
Not all these sent in comments to the Committee, but it is not hard to imagine at least another 4 person years
of effort. This gives the conservative ﬁgure of 50 person years of effort to produce C90.
Between the publication of C90 and starting work on the revision of C99, the C committee met twice a
year for three days; meeting attendance tended to vary between 10 and 20. There was also a signiﬁcant rise
in the use of email during this period. There tended to be less preparation work that needed to be done before
meetings— say 2 person years of effort.
The C99 work was done at the ISO level, with the USA providing most of the active committee mem-
bership. The Committee met twice a year for ﬁve years. Membership numbers were lower, at about 20 per
June 24, 2009 v 1.2 5

0 Introduction 1 Effort invested in producing the C Standard
ISO
JTC 1 Information
Technology
TC 1 SC 2
(Screw Threads)
SC 7
TC 2 (Software and
Systems
TC 4
Engineering)
(Rolling Bearings)
...
...
Programming
SC 22
Languages
TC 243 SC 23
WG 3
(Civil Defence)
...
WG 4
TC 244
SC 36 (COBOL)
(Learning
WG 5
Technology)
(FORTRAN)
...
WG 14
(C)
WG 15
(POSIX)
...
WG 21
(C++)
...
Figure 0.1: The ISO Technical Committee structure— JTC (Joint Technical Committee, with the IEC in this case), TC
(Technical Committee), SC (Standards Committee), WG (Working Group).
meeting. This gives a ﬁgure of 8 person years. During development of C99 there was a signiﬁcant amount of
discussion on the C Standard’s email list; just a week per year equates to more than 2 person years (the UK
and Japanese national bodies had active working groups, many of whose members did not attend meetings).
Adding these numbers up gives a conservative total of 62 person years of effort that was invested in the
C99 document. This calculation does not include the cost of travelling or any support cost (the document
duplication bill for one committee mailing was approximately $5,000).
ISO The C committee structure
The three letters ISO are said to be derived from the Greek isos, meaning “the same” (the ofﬁcial English
term used is International Organization for Standardization, not a permutation of these words that gives the
ordering ISO). Countries pay to be members of ISO (or to be exact, standards organizations in different
countries pay). The size of the payment depends on a country’s gross domestic product (a measure of
economic size) and the number of ISO committees they want to actively participate in. Within each country,
standards’ bodies (there can be more than one) organize themselves in different ways. In many countries it is
possible for their national standards’ body(s) to issue a document as a standard in that country. The initial
standards work on C was carried out by one such national body — ANSI (American National Standards
Institute). The document they published was only a standard in the USA. This document subsequently
X3J11 0 went through the process to become an International Standard. As of January 2003, ISO has 138 national
standards bodies as members, a turnover of 150 million Swiss Francs, and has published 13,736 International
Standards (by 188 technical committees, 550 subcommittees, and 2,937 working groups)(see Figure 0.1).
The documents published by ISO may be formally labeled as having a particular status. These labels
include Standard, Technical Report (Type 1, 2, or 3), and a draft of one of these kinds of documents (there
are also various levels of draft). The documents most commonly seen by the public are Standards and Type 2
Technical Reports. A Type 2 Technical Report (usually referred to as simply a TR) is a document that is
believed to be worth publishing as an ISO Standard, but the material is not yet sufﬁciently mature to be
published as a standard. It is a kind of standard in waiting.
C90
C90 was the ﬁrst version of the C Standard, known as ISO/IEC 9899:1990(E) (Ritchie[1188] gives a history
of prestandard development). It has now been ofﬁcially superseded by C99. The C90 sections ask: What are
6 v 1.2 June 24, 2009