Modern C
Jens Gustedt
To cite this version:
Jens Gustedt. Modern C. Manning, 2019, 9781617295812. �hal-02383654�
HAL Id: hal-02383654
https://inria.hal.science/hal-02383654
Submitted on 15 Sep 2021
HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est
archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non,
lished or not. The documents may come from émanant des établissements d’enseignement et de
teaching and research institutions in France or recherche français ou étrangers, des laboratoires
abroad, or from public or private research centers. publics ou privés.
Distributed under a Creative Commons Attribution - NonCommercial| 4.0 International
License
, Modern C
Jens Gustedt
INRIA, F RANCE
IC UBE , S TRASBOURG , F RANCE
This is the 2nd edition (minor rev. 2) of this book, as of Oct. 10, 2019.
The free version, sample code, links to Manning’s print edition and much more is available at
https://modernc.gforge.inria.fr/
Special thanks go to the people that encouraged the writing of this book by providing me with constructive
feedback, including
colleagues and other interested readers, Cédric Bastoul, Lucas Nussbaum, Vincent Loechner, Kliment Yanev,
Szabolcs Nagy, Marcin Kowalczuk, Ali Asad Lotia, Richard Palme, Yann Barsamian, Fernando Oleo,
Róbert Kohányi, Jean-Michel Gorius ...
Manning’s staff Jennifer Stout, Nitin Gode and Tiffany Taylor, ...
... and the impressive number of reviewers provided by Manning: Adam Kalisz, Andrei de Araujo Formiga,
Christoph Schubert, Erick Nogueira do Nascimento, Ewelina Sowka, Glen Sirakavit, Hugo Durana,
Jean-François Morin, Kent R. Spillner, Louis Aloia, Manu Raghavan Sareena, Nitin Gode, Rafael Aiquel,
Sanchir Kartiev, and Xavier Barthel
Many others have contributed to the success of this book, my sincerest thanks to all of you.
©2016-2019 Jens Gustedt, Strasbourg, France.
This work is licensed under a Creative Commons “Attribution-NonCommercial-
NoDerivatives 4.0 International” license.
, About this book
The C programming language has been around since the early seventies (see Ritchie
[1993]). Since then, C has been used in an incredible number of applications. 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 the ubiquitous presence of C programs and systems, good knowledge
of and about C is much more scarce. Even experienced C programmers often appear to
be stuck in some degree of self-inflicted ignorance about the modern evolution of the C
language. A likely reason for this is that C is seen as an "easy to learn" language, allowing
a programmer with little experience to quickly write or copy snippets of code that at least
appear to do what it’s supposed to. In a way, C fails to motivate its users to climb to higher
levels of knowledge.
This book is intended to change that general attitude, so it is organized in levels that
reflect familiarity with the C language and programming in general. This structure may
go against some habits of the book’s readers; in particular, it splits some difficult subjects
(such as pointers) across levels in order to not swamp readers too early with the wrong
information. We’ll explain the book’s organization in more detail shortly.
Generally, although many universally applicable ideas will be presented, that would
also be valid for other programming languages (such as Java, Python, Ruby, C# or C++)
the book primarily addresses concepts and practices that are unique to C or are of particular
value when programming in the C language.
C versions. As the title of this book suggests, today’s C is not the same language as
the one originally designed by its creator. Right from the start, C has been in a contin-
uous process of adjustment and improvement. Usually, early C is referred to as K&R C
(Kernighan and Ritchie C) after the first book that made the language popular Kernighan
and Ritchie [1978]. Since then, it has undergone an important standardization and exten-
sion process, now driven by ISO, the International Standards Organization. This led to the
publication of a series of C standards in 1989, 1999, 2011, and 2018, commonly referred to
as C89, C99, C11, and C17. The C standards committee puts a lot of effort into guarantee-
ing backward compatibility such that code written for earlier versions of the language, say
C89, should compile to a semantically equivalent executable with a compiler that imple-
ments a newer version. Unfortunately, this backward compatibility has had the unwanted
side effect of not motivating projects that could benefit greatly from the new features to
update their code base.
In this book, we will mainly refer to C17, as defined in JTC1/SC22/WG14 [2018],
but at the time of this writing some compilers don’t implement this standard completely.
If you want to compile the examples in this book, you will need at least a compiler that
implements most of C99. For the changes that C11 added to C99, using an emulation
layer such as my macro package P99 might suffice; the package is available at http:
//p99.gforge.inria.fr.
, ii
C and C++. Programming has become a very important cultural and economic ac-
tivity, and C remains an important element in the programming world. As in all human
activities, progress in C is driven by many factors: corporate or individual interest, pol-
itics, beauty, logic, luck, ignorance, selfishness, ego, sectarianism, ... (add your primary
motivation here). Thus the development of C has not been and cannot be ideal. It has flaws
and artifacts that can only be understood with their historical and societal context.
An important part of the context in which C developed was the early appearance of its
sister language, C++. One common misconception is that C++ evolved from C by adding
its particular features. Although this is historically correct (C++ evolved from a very early
C), it is not particularly relevant today. In fact, C and C++ separated from a common
ancestor more than 30 years ago and have evolved separately ever since. But this evolution
of the two languages has not taken place in isolation; they have exchanged and adopted
each other’s concepts over the years. Some new features, such as the recent addition of
atomics and threads, have been designed in close collaboration between the C and C++
standard committees.
Nevertheless, many differences remain, and generally all that is said in this book is
about C, not C++. Many code examples that are given will not even compile with a C++
compiler. So we should not mix sources of both languages.
Takeaway A C and C++ are different: don’t mix them, and don’t mix them up.
Note that when you are working through this book, you will encounter many lines
marked like that one. These are takeaways that summarize features, rules, recommenda-
tions, and so on. There is a list of these takeaways toward the end of the book, which you
might use as a cheat sheet.
Requirements. To be able to profit from this book, you need to fulfill some minimal
requirements. If you are uncertain about any of these, please obtain or learn them first;
otherwise, you might waste a lot of time.
First, you can’t learn a programming language without practicing it, so you must have
a decent programming environment at your disposal (usually on a PC or laptop), and you
must master it to some extent. This environment can be integrated (an IDE) or a collection
of separate utilities. Platforms vary widely in what they offer, so it is difficult to advise
on specifics. On Unix-like environments such as Linux and Apple’s macOS, you will find
editors such as emacs and vim, and compilers such as c99, gcc, and clang.
You must be able to do the following:
(1) Navigate your file system. File systems on computers are usually organized hier-
archically in directories. You must be able to navigate through these to find and
manipulate files.
(2) Edit programming text. This is different from editing a letter in a word pro-
cessing environment. Your environment, editor, or whatever it is called should
have a basic understanding of the programming language C. You will see that if
you open a C file (which usually has the file extension .c). It might highlight
some keywords or help you indent your code according to the nestedness of {}
brackets.
(3) Execute a program. The programs you will see here are very basic at first and will
not offer you any graphical features. They need to be launched in the command
line. An example of such a program that is launched that way is the compiler.
On Unix-like environments, the command line is usually called a shell and is
launched in a (or the) console or terminal.
(4) Compile programming text. Some environments provide a menu button or a key-
board shortcut for compilation. An alternative to that is to launch the compiler in
the command line of a terminal. This compiler must adhere to recent standards;
don’t waste your time with a compiler that does not conform.
Jens Gustedt
To cite this version:
Jens Gustedt. Modern C. Manning, 2019, 9781617295812. �hal-02383654�
HAL Id: hal-02383654
https://inria.hal.science/hal-02383654
Submitted on 15 Sep 2021
HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est
archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non,
lished or not. The documents may come from émanant des établissements d’enseignement et de
teaching and research institutions in France or recherche français ou étrangers, des laboratoires
abroad, or from public or private research centers. publics ou privés.
Distributed under a Creative Commons Attribution - NonCommercial| 4.0 International
License
, Modern C
Jens Gustedt
INRIA, F RANCE
IC UBE , S TRASBOURG , F RANCE
This is the 2nd edition (minor rev. 2) of this book, as of Oct. 10, 2019.
The free version, sample code, links to Manning’s print edition and much more is available at
https://modernc.gforge.inria.fr/
Special thanks go to the people that encouraged the writing of this book by providing me with constructive
feedback, including
colleagues and other interested readers, Cédric Bastoul, Lucas Nussbaum, Vincent Loechner, Kliment Yanev,
Szabolcs Nagy, Marcin Kowalczuk, Ali Asad Lotia, Richard Palme, Yann Barsamian, Fernando Oleo,
Róbert Kohányi, Jean-Michel Gorius ...
Manning’s staff Jennifer Stout, Nitin Gode and Tiffany Taylor, ...
... and the impressive number of reviewers provided by Manning: Adam Kalisz, Andrei de Araujo Formiga,
Christoph Schubert, Erick Nogueira do Nascimento, Ewelina Sowka, Glen Sirakavit, Hugo Durana,
Jean-François Morin, Kent R. Spillner, Louis Aloia, Manu Raghavan Sareena, Nitin Gode, Rafael Aiquel,
Sanchir Kartiev, and Xavier Barthel
Many others have contributed to the success of this book, my sincerest thanks to all of you.
©2016-2019 Jens Gustedt, Strasbourg, France.
This work is licensed under a Creative Commons “Attribution-NonCommercial-
NoDerivatives 4.0 International” license.
, About this book
The C programming language has been around since the early seventies (see Ritchie
[1993]). Since then, C has been used in an incredible number of applications. 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 the ubiquitous presence of C programs and systems, good knowledge
of and about C is much more scarce. Even experienced C programmers often appear to
be stuck in some degree of self-inflicted ignorance about the modern evolution of the C
language. A likely reason for this is that C is seen as an "easy to learn" language, allowing
a programmer with little experience to quickly write or copy snippets of code that at least
appear to do what it’s supposed to. In a way, C fails to motivate its users to climb to higher
levels of knowledge.
This book is intended to change that general attitude, so it is organized in levels that
reflect familiarity with the C language and programming in general. This structure may
go against some habits of the book’s readers; in particular, it splits some difficult subjects
(such as pointers) across levels in order to not swamp readers too early with the wrong
information. We’ll explain the book’s organization in more detail shortly.
Generally, although many universally applicable ideas will be presented, that would
also be valid for other programming languages (such as Java, Python, Ruby, C# or C++)
the book primarily addresses concepts and practices that are unique to C or are of particular
value when programming in the C language.
C versions. As the title of this book suggests, today’s C is not the same language as
the one originally designed by its creator. Right from the start, C has been in a contin-
uous process of adjustment and improvement. Usually, early C is referred to as K&R C
(Kernighan and Ritchie C) after the first book that made the language popular Kernighan
and Ritchie [1978]. Since then, it has undergone an important standardization and exten-
sion process, now driven by ISO, the International Standards Organization. This led to the
publication of a series of C standards in 1989, 1999, 2011, and 2018, commonly referred to
as C89, C99, C11, and C17. The C standards committee puts a lot of effort into guarantee-
ing backward compatibility such that code written for earlier versions of the language, say
C89, should compile to a semantically equivalent executable with a compiler that imple-
ments a newer version. Unfortunately, this backward compatibility has had the unwanted
side effect of not motivating projects that could benefit greatly from the new features to
update their code base.
In this book, we will mainly refer to C17, as defined in JTC1/SC22/WG14 [2018],
but at the time of this writing some compilers don’t implement this standard completely.
If you want to compile the examples in this book, you will need at least a compiler that
implements most of C99. For the changes that C11 added to C99, using an emulation
layer such as my macro package P99 might suffice; the package is available at http:
//p99.gforge.inria.fr.
, ii
C and C++. Programming has become a very important cultural and economic ac-
tivity, and C remains an important element in the programming world. As in all human
activities, progress in C is driven by many factors: corporate or individual interest, pol-
itics, beauty, logic, luck, ignorance, selfishness, ego, sectarianism, ... (add your primary
motivation here). Thus the development of C has not been and cannot be ideal. It has flaws
and artifacts that can only be understood with their historical and societal context.
An important part of the context in which C developed was the early appearance of its
sister language, C++. One common misconception is that C++ evolved from C by adding
its particular features. Although this is historically correct (C++ evolved from a very early
C), it is not particularly relevant today. In fact, C and C++ separated from a common
ancestor more than 30 years ago and have evolved separately ever since. But this evolution
of the two languages has not taken place in isolation; they have exchanged and adopted
each other’s concepts over the years. Some new features, such as the recent addition of
atomics and threads, have been designed in close collaboration between the C and C++
standard committees.
Nevertheless, many differences remain, and generally all that is said in this book is
about C, not C++. Many code examples that are given will not even compile with a C++
compiler. So we should not mix sources of both languages.
Takeaway A C and C++ are different: don’t mix them, and don’t mix them up.
Note that when you are working through this book, you will encounter many lines
marked like that one. These are takeaways that summarize features, rules, recommenda-
tions, and so on. There is a list of these takeaways toward the end of the book, which you
might use as a cheat sheet.
Requirements. To be able to profit from this book, you need to fulfill some minimal
requirements. If you are uncertain about any of these, please obtain or learn them first;
otherwise, you might waste a lot of time.
First, you can’t learn a programming language without practicing it, so you must have
a decent programming environment at your disposal (usually on a PC or laptop), and you
must master it to some extent. This environment can be integrated (an IDE) or a collection
of separate utilities. Platforms vary widely in what they offer, so it is difficult to advise
on specifics. On Unix-like environments such as Linux and Apple’s macOS, you will find
editors such as emacs and vim, and compilers such as c99, gcc, and clang.
You must be able to do the following:
(1) Navigate your file system. File systems on computers are usually organized hier-
archically in directories. You must be able to navigate through these to find and
manipulate files.
(2) Edit programming text. This is different from editing a letter in a word pro-
cessing environment. Your environment, editor, or whatever it is called should
have a basic understanding of the programming language C. You will see that if
you open a C file (which usually has the file extension .c). It might highlight
some keywords or help you indent your code according to the nestedness of {}
brackets.
(3) Execute a program. The programs you will see here are very basic at first and will
not offer you any graphical features. They need to be launched in the command
line. An example of such a program that is launched that way is the compiler.
On Unix-like environments, the command line is usually called a shell and is
launched in a (or the) console or terminal.
(4) Compile programming text. Some environments provide a menu button or a key-
board shortcut for compilation. An alternative to that is to launch the compiler in
the command line of a terminal. This compiler must adhere to recent standards;
don’t waste your time with a compiler that does not conform.
