On Sat, Aug 1, 2026 at 10:09 AM Alejandro Colomar <[email protected]> wrote:
Well, Keith Bostic wouldn't have suggested that I do this change, and Branden wouldn't be defending that it might make sense to make this change. Since my name came up: I did suggest man page changes, and I should have been clearer about what I meant. I generally think innovation should happen in releases, in response to the user base. That’s the model with the better track record. Somebody ships something, users adopt it or they don’t, and the standards codify existing practice once it reaches consensus. When the standards bodies invent instead of codify, results have been uneven. So if glibc added <nonstring.h> tomorrow, that’s the system working. Ship it, let people vote with their code, and let the standard adopt if it wants. But as I understand it, the man-pages project doesn’t control the code it documents. It describes glibc and the kernel, it doesn’t ship them. A documentation project changing how coding should work in a release it doesn’t control feels different to me. So, my opinion is the man pages shouldn’t be changing the standard includes. Advocating for better usage in the documentation is a different thing, and a good thing. The man pages can even go pretty hard, that’s their job: “Notice the include file is string.h. That’s an historic accident maintained for compatibility reasons; don’t let that fool you, this function doesn’t operate on strings.” That teaches the reader what the function actually does without relabeling where it lives. I think it’s roughly what Joseph is suggesting as well, aiming the clarification at the reader’s understanding rather than at the SYNOPSIS line. —keith [email protected]
