The blog post opens with Unix V4 (November 1973) and a linear allocator buried in the C compiler toolchain. It's a bump allocator: align the size, check if there's room, extend the heap via sbrk() if not, and on failure just exit. No NULL checks for callers. No free. Everything lives for the lifetime of the program. This is not historical curiosity — it's a design choice that modern arena-allocation advocates would recognize instantly. The real find is in Dennis Ritchie's directory: malloc.c, containing malloc() and mfree() with an interface that diverges sharply from what we inherited. Both functions take an explicit first argument — a 'map,' which is just a flat memory region (coremap for physical memory, swapmap for disk swap). mfree() also takes the size of the object being deallocated. The author's excitement is warranted: this interface is structurally superior to what replaced it. You could sandbox a library's allocations by handing it its own region. You could reclaim everything by discarding the region. Heap corruption would be bounded. The implications cascade. The post traces the evolution through V6 (1975), where John Lions' famous Commentary explains the hardware rationale — coremap tracked main memory in 64-byte units, swapmap tracked disk swap in 512-byte units — and where the term 'arena' first appears in the source. The author finds linear allocators reused across programs (diff is a highlight), including a neat trick where diff 'rolls back' its allocator by resetting the pointer — proto-arena semantics without the vocabulary. By V7 (1979), someone — Stuart Feldman, working on both the Fortran 77 compiler and make — introduced an ALLOC(x) macro that wraps sizeof and casts. The author notes this pattern appears only in Feldman's code, evidence of multiple authors with divergent idioms working on the same system. V8 (1985) brings both a wild tryalloc macro that zero-initializes via byte loop AND multiple independent definitions of a new() macro that looks almost identical to how a modern C programmer would write it. The post's implicit argument is the interesting one: the region-explicit malloc() interface was abandoned not because it was worse, but because the hardware constraints that motivated it (separate core and swap maps) dissolved. When you no longer needed to distinguish physical memory from swap at the allocator level, the simpler malloc(size)/free(ptr) interface won on ergonomics. The tragedy is that the structural benefits — memory partitioning, bounded corruption, trivial bulk deallocation — were real and durable, but weren't the reason the interface existed. They were accidental. The writing itself is the draw. The author reads 50-year-old C with genuine delight, connects implementation details to design consequences, and resists the temptation to moralize about how modern systems got it wrong. The tone is closer to a field notebook than a lecture. The code samples are well-chosen — each one demonstrates a specific point about interface design, allocation strategy, or the sociology of a shared codebase. The Cfront/Stroustrup coda linking the new() macros to C++'s new keyword is left tantalizingly incomplete, which is the right move. This is a short piece that punches above its weight because it makes a structural argument through primary sources rather than assertion. The 'lost' malloc() wasn't lost to incompetence — it was lost to the disappearance of the hardware constraint that justified it, and with it went interface properties we're still trying to recover with arena allocators, zone-based memory, and Rust's ownership model.
