Hi Alejandro,
All proposed ISO C changes need to be evaluated according to (at least)
these three dimensions:
* Benefit (for the community of C programmers),
* Cost of adoption (for the community of C programmers),
* Consistency.
Your previous proposal "alx-0097r1 - <memory.h>, the legitimate header for
memcpy(3) et al." evaluates like this, IMO:
* Benefit: Small.
* Cost of adoption: Huge
(there are more than 700000 references to memcpy() alone in Debian sources
[1]).
* Consistency: Reasonable (you have explained why strncpy is actually a "mem"
function).
This proposal [v2] is no longer for ISO C, but — if you want to teach the
community something by modifying the man pages — needs to be evaluated according
to the same criteria.
* Benefit: None.
* Cost of adoption: Moderate
(because these 5 functions are not frequently used).
* Consistency: Totally negative.
- memmem() is a generalization of memchr(), therefore it belongs in the
same header file, namely <string.h>.
- memrchr() is an analogue to memchr(), therefore likewise it belongs in
<string.h>.
- mempcpy() is a variant of memcpy(), therefore likewise it belongs in
<string.h>.
- strndupa() is a variant of strndup() which is declared in <string.h>,
therefore it belongs in <string.h> as well.
Please do us the favour to evaluate your proposals according to these
dimensions by yourself, before spreading them.
And, of course, for man page changes, consider the authoritative source.
For example, memfrob() exists only in glibc [2], therefore its authoritative
documentation is in the glibc manual [3], and it says "It is declared in
string.h." The man pages MUST say the same thing.
Thanks.
Bruno
[1] https://codesearch.debian.net/search?q=%5Cbmemcpy%5Cb&literal=0
[2]
https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=tree;f=platforms/various-symlists
[3] https://sourceware.org/glibc/manual/2.44/html_node/Obfuscating-Data.html
