The Quiet Power Grab That’s Changing How You Write C

If you’ve ever written memcpy(dest, src, n) and thought nothing of it, you’re about to feel very uncomfortable. For decades, string.h has been the home of memory functions—memcpy, memset, memmove, the whole gang. It’s been that way since 1989. It’s stable. It’s boring. It’s reliable.

Now one man wants to move them all to memory.h. And he might actually pull it off.

Alejandro Colomar, the current maintainer of the Linux manpages project, has proposed resurrecting memory.h—a header that died in the 1990s, buried under the weight of string.h convention. His reasoning? Logical. Elegant. Disruptive. The man who controls the man pages controls the minds of every C developer who hasn’t read the standard.

Reading the mailing list thread, you can feel the tension. It’s not about code—it’s about who gets to decide what’s normal. Colomar isn’t forking glibc or rewriting the compiler. He’s changing the documentation. And that’s the real battleground.

Here’s the uncomfortable truth: documentation is not a record of what exists; it’s a blueprint for what becomes normal. When man pages say #include , every tutorial, every Stack Overflow answer, every university course reproduces that pattern. Move it to memory.h, and within a decade, new C programmers will look at string.h and wonder why anyone would put memory functions in a string header.

I’ve been watching this unfold. The reactions are split between “finally, someone fixing the mess” and “who gave this person the right to unilaterally decide?” Both sides have a point—but the controversy itself is the story.

Look, I get it. string.h is a historical accident. memcpy has nothing to do with strings. A clean separation between string.h (for strcpy, strlen) and memory.h (for memcpy, memset) is objectively better API design. But here’s the thing: consensus built over 30 years can be undone by one person’s aesthetic preference.

This is either brilliant or terrifying—and I’m leaning toward terrifying. Not because the change is wrong, but because of what it represents. If a single maintainer can reshape how we think about C’s standard library by changing man pages, then every developer is at the mercy of whoever writes the docs. That’s not governance. That’s a coup disguised as a pull request.

Colomar’s proposal isn’t just about headers. It’s a test case for the power of documentation. We’ve been taught that code is king, but the real influence lies in the system that describes that code. The man pages are the lens through which an entire generation of C programmers sees the standard library. Change the lens, change the reality.

So what happens next? The C standard committee hasn’t blessed this. The compiler hasn’t changed. But if the man pages move, the ecosystem will eventually follow. Package maintainers will update headers. Linters will flag #include for memory functions. And within a few years, you’ll have a schism—old code using string.h, new code using memory.h, both technically correct but culturally incompatible.

This is the moment where we decide whether documentation is a coordination layer or a governance layer. If you think this is just about a header file, you’re missing the point entirely. The next time you type #include , ask yourself: who decided that? And more importantly, who gets to change it?