The New C Standard
An Economic and Cultural Commentary
Derek M. Jones
derek@knosof.co.uk
Copyright ©2002-2009 Derek M. Jones. All rights reserved.
CHANGES
-5
CHANGES
-5
Copyright © 2005, 2008, 2009 Derek Jones
The material in the C99 subsections is copyright
©
ISO. The material in the C90 and C
++
sections that is
quoted from the respective language standards is copyright © ISO.
Credits and permissions for quoted material is given where that material appears.
THIS PUBLICATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE PARTICULAR WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.
THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS.
CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN.
Commentary
The phrase at the time of writing is sometimes used. For this version of the material this time should be taken
to mean no later than December 2008.
24 Jun 2009 1.2 All reported faults fixed.
38 references added + associated commentary.
29 Jan 2008 1.1 Integrated in changes made by TC3, required C sentence renumbering.
60+ recent references added + associated commentary.
A few Usage figures and tables added.
Page layout improvements. Lots of grammar fixes.
5 Aug 2005 1.0b Many hyperlinks added. pdf searching through page 782 speeded up.
Various typos fixed (over 70% reported by Tom Plum).
16 Jun 2005 1.0a Improvements to character set discussion (thanks to Kent Karlsson), margin
references, C99 footnote number typos, and various other typos fixed.
30 May 2005 1.0 Initial release.
v 1.2 June 24, 2009
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 flexible 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/m
2
stock produces a stack of paper
that is 9.2cm (3.6inches) deep.
June 24, 2009 v 1.2
Preface
-3
Preface
-3
The New C Standard: An economic and cultural commentary
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 first, 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 significant 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 influence on the design of C (mostly BCPL and Algol 68).
The discussion in these subsections is also likely to have been influenced 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 significantly 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 benefit 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 specific 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 field of cognitive psychology and an attempt has been made to underpin the
discussion with the results of studies performed by researchers in this field.
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.
Aristotle Meta-
physics book II
Our attitude towards what we listen to is determined by our habits. We expect things to be said in the
ways in which we are accustomed to talk ourselves: things that are said some other way do not seem the
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 significantly more often in an everyday context. Using existing practice provides a
benefit purely because it is existing practice. For a change to existing practice to be worthwhile the
total benefit has to be greater than the total cost (which needs to include relearning costs),
2.
when performing a task people make implicitly cost/benefit 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 benefit 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 efficient use of
June 24, 2009 v 1.2
