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 <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2820 bytes --]

Hi Joseph,

> Date: 2026-07-31 22:42:00+0000
> From: Joseph Myers <josmyers@redhat.com>
>
> 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
> josmyers@redhat.com
> 

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]