Re: on the irresponsibility of pursuing C language reform

[Joseph Myers <josmyers@redhat.com>]

On Sun, 2 Aug 2026, Alejandro Colomar wrote:

> Joseph was concerned that this documentation would conflict with many
> documents saying that <memory.h> is deprecated.  Luckily, I've never
> seen such a document, so we can assume they don't exist (unless people
> show evidence).  I'll dismiss his negative vote, since his technical
> reasons are incorrect.  Also, <memory.h> is undoubtedly more portable 
> than a new <stdmem.h>.

The glibc manual nowhere mentions <memory.h>.  That's pretty clear 
evidence the header is a relic of the days when glibc just took any 
interface some 1980s Unix had rather than trying to have a cleaner API of 
more current relevance.

My main concern, in any case, is that man-pages should describe the world 
as it is, not as you'd like it to be; they should follow, not lead, on any 
proposed changes; they should promote portable coding practices and using 
existing standard interfaces in the absence of broad consensus (not just 
your opinion; not just an opinion based on dismissing all the views 
against) of a clear technical deficiency in those interfaces; that anyone 
advocating for an interface change should avoid using man-pages as part of 
that advocacy, only eventually updating it after the debate has concluded 
once there is consensus on what the conclusion of the debate was but 
ensuring the man-pages don't take any one side of the debate before then.

I suggest we need to figure out how to generate man pages from the glibc 
manual so that people who prefer documentation in that format can have 
documentation of glibc interfaces that's maintained by a proper consensual 
process rather than following one person's opinion.

-- 
Joseph S. Myers
josmyers@redhat.com