3
PRELIMINARIES. It has been a long time since the programming language C is around; the main references
for it was traditionally be the book written by its creators Kernighan and Ritchie [1978]. Since that time C
has seen a fabulous distribution, programs and systems written in C are all around us, in personal computers,
phones, cameras, set-top boxes, refrigerators, cars, mainframes, satellites, basically in any modern device that
has a programmable interface.
In contrast to that ubiquitous presence, good knowledge of and about C seems to be much more scarcely
distributed. Even confirmed C programmers often seem to be stuck in some self-inflicted ignorance about the
modern evolution of the C language. One of the reasons for this is probably that C is an “easy to learn” language:
even without much programming knowledge C lets us quickly write or just copy some code that will, often only
seemingly, do the task that we want it to do. So somehow C is missing to offer an incentive to those working with
it to climb to higher levels of knowledge.
This book is intended to change that general attitude. It is organized in chapters called “Levels” that sum-
marize levels of familiarity with the C language and programming in general. Some features of the language are
treated in parts on the different levels according to their difficulty. Most prominently pointers are only partially
introduced at Level 1 and then fully treated at Level 2. As a consequence, we have a lot of forward references to
stave off the impatient reader.
As the title of this book suggests, today’s C is not exactly the same as the one that was originally designed
by its creators, usually referred to as K&R C. In particular it has undergone an important normalization and
extension process that is now driven by ISO, the International Standards Organization. This has lead to three
major publications of C standards in the years 1989, 1999 and 2011, commonly referred to as C89, C99 and
C11. The C standards committee puts a lot of efforts into guaranteeing backwards compatibility such that code
written for one language, C89 say, should compile to a semantically equivalent executable with a compiler that
implements a newer version. Unfortunately, this backwards compatibility also has the unwanted side effect that
projects that could much benefit from new features miss the opportunity to update.
In this book we will mainly refer to C11, see JTC1/SC22/WG14 [2011], but at the time of this writing many
compilers don’t implement this standard completely. If you want to compile the examples of this book, you’d
need at least a compiler that implements most of C99. For the ∆ that C11 put on top of C99, using an emulation
such as my macro package P99 might suffice, you may find it at http://p99.gforge.inria.fr/.
Programming has become a very important cultural and economical activity and C is just in the middle of it.
As all human activities progress in C is driven by many factors, company or individual interest, politics, beauty,
logic, luck, ignorance, selfishness, Ego, sectarianism, ... (add your primary motive, here). Thus the development
of C has not been and cannot be ideal. It has flaws and artifacts that can only be understood from the historic and
societal context.
An important context in which C developed was the early appearance of its sister language C++. One com-
mon misconception is that C++ had evolved from C by adding its particular features. Whereas this is historically
correct (C++ evolved from an very early C) it is not much relevant, today. Fact is, that C and C++ separated from
a common ancestor more than 30 years ago, and that they evolved separately since then. But this evolution of
both languages has not taken place in isolation, both have integrated concepts of the other over the years. Some
new features, such as the recent addition of atomics and threads have been designed in close relationship between
the two committees.
Nevertheless, many differences prevail and generally all that is said in this book is about C and not C++.
Most code examples that are given shouldn’t even compile with a C++ compiler.
Rule A C and C++ are different, don’t mix them and don’t mix them up.
ORGANIZATION. This book is organized in levels. The starting level, encounter, will introduce you into the very
basics of programming with C. Even if you don’t have much experience in programming, at the end you should
be able to understand the structure of simple programs and be able to start to write your own.
Then,
acquaintance, details most principal concepts and features such as control structures, data types,
operators and functions. It should give you a deeper understanding of the things that are going on when you
run your programs. This knowledge should be sufficient for an introductory course to Algorithms, e.g, with the
noticeable particularity that pointers aren’t fully introduced here, yet.
Level cognition goes to the heart of the C language. It fully introduces pointers, familiarizes you with C’s
memory model, and allows you to understand most of C’s library interface. Completing this level should enable
you to write C code professionally, therefore it starts with a discussion about the writing and organization of C
programs, don’t miss it. I personally would expect anybody who graduated from an engineering school with a
major that is related to computer science or programming in C to master this level. Don’t be satisfied with less.
Experience then discusses more involved topics, such as performance, reentrancy, atomicity, threads and
type generic programming. These are probably best discovered where you go, that is when you encounter them
in the real world. Nevertheless, as a whole they are necessary to round off the picture and to provide you with a
full expertise in C. Anybody with some years of professional programming in C or who heads a software project
that uses C as its main programming language should master this level.
Last but not least comes ambition. It discusses my personal ideas of a future development of C. C as it is
today still has some rough edges and particularities that only have historical justification. I propose possible paths
to improve on the lack of general constants, to simplify the memory model, and more generally to improve the
modularity of the language. This level is clearly much more specialized than the others, most C programmers can
probably live without it, but the curious ones among you could perhaps take up some of the ideas.
