Alejandro Colomar <alx@kernel.org> writes:

> [[PGP Signed Part:No public key for EB89995CC290C2A9 created at 2026-08-02T23:34:34+0200 using RSA]]
> Hi Maciej,
>
>> Date: 2026-08-02 22:23:36+0100
>> From: "Maciej W. Rozycki" <macro@orcam.me.uk>
>>
>> What problem are you trying to fix anyway, what's wrong with 
>> using <string.h> for the APIs in question?
>
> Programmers misunderstand these functions (some more than others), and
> think they are appropriate for handling strings in ways that they are
> inappropriate.
>
> If <string.h> was described as providing functions that exclusively
> handle strings, then programmers that only need to handle strings
> would naturally self-limit to functions from this header file.
>
> Those programmers that need more niche memory functions --maybe
> because they need to handle a substring, or maybe because they need to
> handle a utmp(5) fixed-width null-padded character array-- can resort
> to <memory.h>, but that comes with the implied warning that those
> functions are not the simple interfaces that <string.h> probides; they
> are sharper: you can do more with them, but you need to be more
> careful.
>
> Most programmers can live in the safe bubble of <string.h>: those
> functions always require a string as input, and always provide a string
> as output.  Plain and simple.  It's difficult to write bugs when using
> those.
>
> That's the rationale.

I do not follow.

C has no namespaces, let alone qualified imports.

The name of a header providing some function is thus inconsequential.

Indeed, these functions are provided by many headers outside of these
two (by accident most often, but sometimes intentionally).

No programmer is able to safely use any C function until they read its
documentation.

This goes doubly so for functions operating on bit soup, like mem* and
str*.
-- 
Arsen Arsenović