Every program using malloc is technically undefined behavior in C++

The P0593 saga still goes on

I stumbled onto something fascinating last week while digging through Patrice Roy’s new book on C++ memory management. Not because the book was particularly good—it’s actually riddled with integer overflows that would make any systems programmer cringe—but because it made me realize I’ve been writing subtly broken arena allocators for years. And here’s the kicker: so has everyone else, including the folks writing popular blog posts about it.

Chris Wellons (nullprogram) just published an article claiming he found this subtle lifetime bug in his own C++ arena allocators. He’s right, technically. The same guy who’s been evangelizing arena allocation for years, showing us how to build hash maps that compose beautifully with arenas, how to use them for scratch memory that makes dynamic allocation feel like garbage collection—even he got the lifetime semantics wrong. But after spending hours benchmarking and testing with every sanitizer known to mankind, I’m here to tell you that this “bug” is the least interesting part of the story.

The real story? The C++ committee spent six years arguing about this exact issue (P0593, if you want to lose a weekend reading committee papers), finally admitting in C++20 that the entire C ecosystem had been “undefined behavior” according to their rules. Meanwhile, arena allocators are either insanely fast or completely unusable, depending on one tiny detail nobody talks about.

The Speed That Makes You Question Everything

Let me show you some numbers that made me do a double-take. I ran these benchmarks on a bog-standard Linux box with a 3.8GHz CPU, nothing fancy, just good old GCC with -O2. The performance gap was so absurd I thought I’d screwed up the measurements.