Re: on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>)

Alejandro Colomar <[email protected]> Sat, 1 Aug 2026 00:52:39 +0200

Newsgroups	gmane.linux.man,gmane.comp.lib.gnulib.bugs,gmane.comp.lib.glibc.alpha
Message-ID	<am0lAEb1wuCJPDk7@devuan>

Hi Joseph,

> Date: 2026-07-31 22:42:00+0000
> From: Joseph Myers <[email protected]>
>
> On Sat, 1 Aug 2026, Alejandro Colomar wrote:
> 
> > > When an API has been in <string.h> since 1989, that means documenting 
> > > <string.h> as the main location for that API - not some other location one 
> > > person thinks is better and that most of the community has never heard of.
> > 
> > FWIW, the APIs have been in <memory.h> since 1986 in 4.3BSD, and in
> > System V they go back further to 1983.
> 
> In other words, they were in that header for 6 years, and it's been 
> implicitly obsolescent by virtue of the standard choice for the 37 years 
> since then.

Yes.  And I'm trying to revert the implicit obsolescence.  Obsolescence
isn't a one-way process.  Sometimes, evidence shows up, and the obsolete
feature must come back for $reasons.

FWIW, memccpy(3) was resurrected in C23 back from a cold death it had
been suffering since forever.  And that was less justified.

> Standards involve accepting agreed compromises that might not have been 
> your first choice, rather than endlessly relitigating past disputes 
> without new evidence or changed circumstances.  In this case, the choice 
> of where to put the functions in C89 was an agreed compromise that 
> implicitly obsoleted the previous location, and should have put an end to 
> any arguments that <string.h> was a bad location for those functions in 
> the absence of clear new evidence.

I agree that it wasn't necessarily obvious back then that the movement
to <string.h> was bad.  While I blame the C89 Committee for other stuff
they should have been aware of, this isn't one of them.

But now in 2026, we see that there have some been problems.

> We have plenty of clear evidence for 
> confusion about strn*; we don't about mem*.

Thanks!  Now we have a common ground.

Indeed, while there might be a minimal problem with mem*() --the fact
of not starting by str makes them less misused--, the important problem
is strn*().

The solution of moving both mem*() and strn*() to <memory.h> and leaving
just str*() in <string.h> is a consistent one, because <string.h> then
remains strictly for string APIs, and <memory.h> is for the rest of byte
handling.

It wouldn't be reasonable to move strn*() to <memory.h>, and then leave
mem*() in <string.h>, of course.

Similarly, it wouldn't be reasonable to more strncpy/cat() to <memory.h>
and leave the rest of strn*() and all of mem*() in <string.h>.

This movement, while a bit massive, is consistent and self-explicative.
That is, the only reasonable way to move strncpy/cat() is to also move
strn*() and mem*().

Cheers,
Alex

> 
> -- 
> Joseph S. Myers
> [email protected]
> 

-- 
<https://www.alejandro-colomar.es>

signature.asc (application/pgp-signature, 833 B)