Preface
Memory-safety vulnerabilities are usually presented as a collection of familiar categories: buffer overflows, use-after-free, double frees, dangling pointers, integer overflows, and so on. Each category has its own terminology, examples, mitigations, and history. But this way of looking at the problem can obscure something fundamental: these are not necessarily different kinds of failure. They can be different manifestations of a deeper failure — the violation of a semantic invariant.
This book brings together and develops a perspective in which these familiar vulnerabilities can be understood in those terms. The idea of viewing programming errors through violated invariants has a long history across programming languages, formal methods, and software engineering. The aim here is not to claim that perspective as new, but to apply it systematically to memory safety and to bring several related ideas into closer alignment
A semantic invariant is a relationship that must remain true for a program to behave as intended. In C, many such relationships exist only implicitly. A pointer must refer to a live object; an array index must remain within its bounds; an allocation must eventually be released, but not released twice; a length must correspond to the amount of storage actually available. The language often does not express these relationships strongly enough to enforce them. They therefore become obligations placed on the programmer.
When one of these obligations is broken, we observe what the security community calls a vulnerability. The buffer overflow, the use-after-free, and the double free are the visible manifestations. Beneath them lies the violated invariant.
This perspective changes the question we ask. Instead of asking only "which vulnerability has occurred?", we can ask "which semantic invariant was supposed to hold, and why was the program unable to preserve it?" This provides a common conceptual layer beneath the familiar vulnerability taxonomy and helps connect ideas that are often discussed separately.
It also leads naturally from the analysis of C to the design of programming languages. If an invariant is important enough that programmers must continually preserve it, perhaps it should not remain merely an informal obligation. A memory-safe language can make such relationships explicit and arrange for them to be enforced by the language, its type system, its runtime, or some combination of these. What C leaves as programmer responsibility can, in a different language, become a property guaranteed by construction.
The purpose of this book is therefore not simply to catalogue the weaknesses of C, nor to argue that one language is safer than another. It is to bring together a way of understanding the relationship between program semantics, vulnerability, and language design, and to use that perspective to examine memory safety more systematically.
The central claim is simple:
Memory-safety vulnerabilities are violations of semantic invariants, and the design of a memory-safe programming language is, in significant part, the design of mechanisms that make those invariants explicit and enforceable.
The chapters that follow explore this proposition, beginning with the apparently disparate failures that occur in C and working toward the principles they have in common. The hope is that, by looking beneath vulnerability categories to the invariants that give rise to them, we can bring together several strands of thinking about memory safety and see more clearly both the limitations of C and the possibilities for designing languages in which entire classes of errors need never arise.
A substantial portion of the initial manuscript was generated with the assistance of artificial intelligence. The author provided the underlying concept and creative direction and worked extensively with AI tools throughout the development of the book, selecting, restructuring, editing, rewriting, and refining the material. The final book reflects the author’s creative vision and editorial decisions.
I am grateful to the researchers, engineers, and wider community whose work has made these artificial intelligence tools possible.