By Jonathan Corbet, September 28, 2026
\nAs a professor of biomedical engineering, Martin Uecker perhaps does not fit the profile of a typical presenter at Kernel Recipes. He is, however, a longtime Linux user, and works on free software for controlling magnetic resonance imaging (MRI) scanners. He was at the conference to talk about the C programming language, the specific problem of undefined behavior in C, and whether it can eventually be made into a memory-safe language.
\nWhy bother with C in 2026? It is, he said, still a great language. C is\nportable, stable over the long term, offers fast compilation, and the\nresulting binary code is fast. "What you see is what you get"; it\nis easy to look at C code and have some idea of what the computer will\nactually do. There are a lot of tools for working with the language, and C\ngets out of the way when necessary.
\nC does have a long history, and that affects the language as we see it today, he said. The C89 standard had to cope with a wide variety of hardware, including machines with signed-magnitude or one's-complement integer representations, segmented memory, exotic pointer representations, and surprising sizes for types. Some Honeywell machines, for example, had nine-bit bytes. That greatly complicated the task of writing a standard that would enable the writing of portable code.
\nThe approach that was taken was to define the semantics of the language in\nterms of an abstract machine. All operations are to be executed as if they\nhad run on that abstract machine, which may not exactly match the actual\nhardware. The observable behavior of the program must be what the abstract\nmachine would have done. The "observable" part matters: access to\nvolatile variables, being defined as observable, must happen\nexactly according to the abstract machine; everything else just has to\nproduce the same eventual result.
The standard gives a lot of freedom to compiler implementers; only the\nobservable behavior has to be preserved. There are many aspects of that\nbehavior that are either undefined or implementation-defined. These are\nnot observable behavior, and thus do not constrain what compiler\nimplementers can do. There are, of course, other specifications that\ncan constrain compiler developers where the C standard does not;\nthese include ABI requirements, standards like POSIX, or the need for\nbackward compatibility.
\nUndefined behavior comes about when a program does something that is either\nnot portable or not defined by the standard at all. In such cases, the C89\nstandard states that it "imposes no requirements" on the\nimplementation. Undefined behavior exists for a number of reasons.\nIt allows implementations to support extensions, manage\ninteractions with hardware-based safety mechanisms, and perform aggressive\noptimization, all while allowing difficult-to-detect errors to be ignored.\nIt explicitly gives the compiler the right to ignore whole classes of\nhard-to-detect errors.
\nThe problem, Uecker said, is that the standard allows a compiler to do\nanything in response to undefined behavior, up to the point of\ninvoking nasal\ndemons. If a program contains any undefined behavior at all, according\nto compiler writers, then it has no expected semantics. The C++23 standard\ngoes further to explicitly state that the standard imposes no requirements\nfor these programs. That has led to widespread disagreements between\ndevelopers about what can be expected from the language.
\nFor example, if you zero an entire structure (perhaps with a call to memset()),\nthen write to specific fields, what will happen if you read from any\npadding bytes in that structure? Might they contain security-relevant\ndata? A\n2015 survey showed that there was no consensus on what should happen in\nthat case. Or consider this simple code:
extern int x;\n int f(int a, int b)\n {\n x = b ? 42 : 43;\n return a/b;\n }If b is zero, then the return statement is a division by\nzero, which is undefined behavior. In this case, is the compiler entitled\nto omit the test entirely and just execute x = 42? After all, the\nb = 0 case has no expected semantics, and can thus be ignored.\nThere are compilers that will do exactly that. In the undefined-behavior\ncase, the store to x is not observable behavior. But now consider\nthis case:
extern void g(int x);\n int f(int a, int b)\n {\n g(b ? 42 : 43);\n return a/b;\n }This might seem to be the same situation, with the compiler being entitled\nto remove the test and just pass 42 to g(), and some compilers\nhave treated that way — but that compiler behavior was a bug. Imagine a\ndefinition of g() that calls exit() if b is\nzero. In that case, the division will never happen and the program's\nbehavior is not undefined. So eliding the test and simply passing 42 to\ng() is incorrect.
One more interesting case:
\n volatile int x;\n int foo(int a, int b, bool store_to_x)\n {\n if (! store_to_x)\n return a/b;\n x = b;\n return a/b;\n }The question here is: can the compiler hoist the final division operation\nabove assignment to x? If there are no semantics associated with\nthe b = 0 case, then there is no change in observable behavior.\nThis, too, is something compilers have done, but the C23 standard added a\n"no time travel" stipulation to disallow it. In C++, instead, hoisting\nmust be explicitly prevented by inserting a call to\nstd::observable_checkpoint().
Time-travel bugs should eventually go away, but there are a lot of other\nsituations where, even if the standard is clear, compiler writers often\ndisagree. These include reading of uninitialized variables (which is\nalmost always defined), and equality comparisons of pointers, which\nis always defined, but is also miscompiled by both Clang and GCC.
\nTo try to address all of these problems and more, the C committee runs three study groups focused specifically on the memory object model, memory safety, and undefined behavior. There are currently about 100 instances of undefined behavior in the C standard, but the in-progress C2y draft has removed 45 of them. The situation is indeed getting better.
\nThere is an increasingly rich set of tools aimed at finding issues: compiler warnings, static analyzers, sanitizers, LLM-based tools, formal verification, and more. The number of situations where a compiler will emit a warning where possible undefined behavior is detected is growing; recent examples include better warnings for integer overflows and potential use-after-free situations. Static analyzers are available as standalone tools, but are also increasingly being built into the compilers themselves; GCC can now warn about a number of potential buffer-overflow situations, for example. Sanitizers work by inserting run-time checks; they can catch a lot of undefined behavior and, in trapping mode, be used for hardening as well.
\nMemory safety has never been one of C's strong points, but Uecker wanted to make the point that it can be improved. That problem breaks down into three sub-problems: type safety, spatial memory safety, and temporal memory safety.
\nC, he said, has a strong type system, and the remaining problems are\nfixable. Tagless unions, for example, can create type confusion, but the\ncompiler can enforce types with some additional annotations. New\ndiagnostics can catch unsafe casts from void. Type checking\nacross translation units is traditionally not a huge problem in C, since\nheader files are used to ensure consistent types, but the situation could\nbe improved with a link-time checker.
Spatial memory safety — bounds checking — is a partially solved problem;\nthe compilers can perform array-bounds checking in many situations now. In\nsome cases, some code changes are needed to fully benefit from this\nchecking. Use of the counted_by attribute\ncan enable checking for flexible array members, for example.
\nTemporal memory safety — avoiding use-after-free bugs and the like — is\nharder, Uecker said, and Rust definitely has an advantage there. Still,\nbetter temporal memory-safety enforcement is possible. Architectures like\nCHERI\ncan help here is well. Fil-C can find a\nlot of temporal-safety bugs.
\nCan all of these tools and language changes get us to full memory safety? Completely solving the problem will require either expensive run-time checking or formal verification, he said. In the near future, the most complete results will be had with the combination of a restricted language and formal verification tools.
\nOverall, he concluded, C is still a living language and is still improving.\nThe C23 standard removed a number of problematic features, including\nold-style (K&R) function definitions, support for sign-magnitude and\none's-complement machines, and trigraphs. It added bit-precise integer\ntypes, checked integer operations, and more. C2y will go further, adding\ncase ranges, named for loops, the _Countof() macro to\ndetermine array lengths, and a lot of "demon removal". It will not\nachieve full memory safety for C, but that is an eventual possibility, and\nwill become more practical over time. He ended by encouraging interested\npeople to participate in the working groups.
The video and slides from this\ntalk are available.
\n[Thanks to the Linux Foundation, LWN's travel sponsor, for supporting my\ntravel for this event.]
","headings":[{"level":1,"text":"Reducing undefined behavior in the C language","id":"reducing-undefined-behavior-in-the-c-language"}]}}