On 12/13/22 23:05, Alejandro Colomar wrote:
Hi Jakub, On 12/13/22 21:56, Jakub Wilk wrote:The sheer size of this page make it almost unusable for me.
Moreover, I'd like to ask, what's your use case for these (string copy) pages? And how am I impeding it?
- stpcpy(3) - strcpy(3) - strcat(3) - stpncpy(3) - strncpy(3) - strncat(3)Except for the last one, they are so simple in terms of the byte operation that they perform, or the return value, that the pages are useless. Once you know what they do, you don't forget (and I bet you know what they do). And even strncat(3) is simple, when you understand it.
The return value is simple: 'r' functions return dst. 'p' functions return a pointer past the last non-null character written.
The operation of 'cat' functions is simple: strlen(dst), and append a string there.The operation of 'st.cpy' functions is even simpler: read a string, and copy it at dst.
The operation of st.ncpy(3) is slightly less intuitive (probably due to misdesign, the name doesn't match what they do): read a string, and copy it with truncation into a null-padded character sequence in a fixed-width array.
strncat(3) is the most misdesigned of all: it reads a character sequence from a null-padded fixed-width array, and creates a string out of it.
That covers it all. If I were to put those paragraphs in a separate page for each function, what good would they do?
So, the pages are not very informative for those who already know. And for those who don't know, I very much prefer that they read the entire page.
Cheers, Alex
Please don't merge it. * Alejandro Colomar <alx.manpages@xxxxxxxxx>, 2022-12-13 00:00:stpecpy(3), stpecpyx(3) Not provided by any library.Then they don't belong in the man-pages project.strscpy(3) Not provided by any library. It is a Linux kernel internal function.Ditto.And strictly speaking, I shouldn't document strlcpy(3bsd) and strlcat(3bsd) either because they're not provided by our libc; libbsd already has manual pages for them, anyway.Regarding this, the intention of the page is not to coldly document the behavior of functions in terms of the byte operations they perform. That's what has been done until now, and the result is what we know: many string copy functions are dreaded (e.g., strncpy(3)), because most programmers don't use them correctly.This new page instead, shows all string copying functions, including those developed by other systems as alternatives to the standard ones. They did it for a reason: the standard functions don't cover all use cases, and there's a need to roll your own. But rolling your own is bad. It's better if someone explains what alternative string copy functions exist, when they are more appropriate than libc ones, and when they are not. Even the old pages documented strlcpy(3) a little bit!I suggest for a first release using the new page string_copy(7). I'll rewrite anyway strcpy(3) and all others to be minimal, _and_ be reductions of string_copy(7), for fast lookup.Cheers, Alex
-- <http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
