98 Modern C, gathered up
What to know first
Looking back
Chapter 1 declared this book “not an introduction written by the inertia of old usage but an introduction setting out from today’s C”. Then, now that the book has been read through, how does the C the reader has learned differ from the old C?
A. It is not that the list of syntax differs but that the criterion differs. A book of old usage teaches “write it this way and it works”, while this book taught “write it this way and it is within the contract” — initialise before use (chapter 23), handle the boundary and the size together (chapter 38), confirm failure as a value (chapter 51), avoid shortcuts outside the contract (chapter 52), check with tools (chapter 17). C23′s new syntax appeared as tools that make that criterion easier to keep. The retrospect below is that list.
The need for this chapter, and its context
By the end of this chapter
The questions this chapter answers
- Where is it good to go from here?
98.1 Retrospect — the C23 already used
This book did not introduce the new standard separately but used it naturally where it was needed. Gathered together it comes to this much.
| what is C23′s | where first met | what it made easy |
|---|---|---|
the bool, true, false keywords | chapter 30 | judgement as a value without a header |
nullptr | chapter 36 | removing NULL’s ambiguity |
| two’s complement fixed | chapter 7 | the end of worrying about the portability of sign representation |
[[nodiscard]] | chapters 37 and 51 | the compiler blocks the mistake of forgetting to confirm failure |
[[fallthrough]] | chapter 31 | the intent of switch fallthrough as documentation |
the ckd_add family | chapter 52 | overflow as a value rather than UB |
alignof | chapter 37 | querying alignment requirements at the level of the language |
| the removal of trigraphs | chapter 9 | tidying up a scar of the character-code era |
the relaxation of va_start | chapter 58 | removing the excess of variadic arguments |
Table 99.1
One direction is visible — contracts more explicit, mistakes caught sooner. This table is the concrete content of chapter 1′s “C itself is showing signs of change”.
98.2 The practices of modern C — one sheet of guidance
Compressing this whole book into practical precepts gives this.
Building and tools. Turn the warnings on (-Wall -Wextra). Run tests with sanitizers (ASan, UBSan). Where possible, cross-check with two compilers (chapter 17).
Declarations and types. Initialise at the point of declaration. Leave what will not change as const. Where the size is a contract, use the fixed-width types of <stdint.h>. Keep sizes and indexes consistently in the size_t family (chapter 29′s trap of mixing signedness).
Memory. Boundaries are always explicit — an array and its length travel together. Confirm a pointer’s validity before writing through it. For dynamic allocation, settle the owner, and empty the pointer after freeing. Solve it with automatic lifetime where possible (chapters 38 and 45).
Errors. Report failure as a value, and check return values. Internal invariants with assert, what came from outside with checks at run time (chapter 51).
Contracts. Judge not by “it ran on my computer” but by “is it correct on the abstract machine” (chapters 12 and 52).
Components. Know the contracts of the standard library and choose accordingly, and lay components with checking built in over the repeated danger zones (chapter 61 and Part XII).
Q. Where is it good to go from here?
A. Three branches are recommended. Depth — the places this book has left the door open to: data structures and algorithms (chapter 46′s linked structures), concurrency (chapter 12′s multicore and C11 atomics), systems programming (files and networks are the world of platform APIs). Breadth — the neighbouring languages: when looking at C++, Rust or Zig, the sense of memory, contracts and representation learned in this book translates over as it stands (as foretold in chapter 1). Practice — reading directly the source of the projects named in chapter 96. Well-written C code like SQLite or curl is a textbook in which every theme of this book is alive in the flesh.
And it is worth remembering too that the standard document itself has now become a text you can read — seen through the viewpoint of “a contract”, it becomes clear why that curt document was written as it was.
98.3 Books to read next, and the standard document
For readers who will not stop here, further reading has been gathered separately — that is appendix D. C is a language unusually empty in the shelf right after the introductory books, but over the last few years books filling that shelf have been appearing. The appendix notes those books’ strengths and weaknesses, together with how actually to obtain the standard document this book has all along called “the contract” (buying it, and downloading the free drafts).
98.4 Finally
This book began in chapter 4 by drawing the computer as three parts. That picture promptly collapsed honestly — memory became a ladder, execution overlapped, an editor cut in — and what remained in its place was the contract. That knowing C is not memorising syntax but being able to read that contract is the one thing this book wanted to say.
To the reader who has come this far by reading alone, only one thing now remains — writing what was read as your own code. May the journey be a good one.