Hi Keith, On Mon, Jul 15, 2024 at 02:47:19PM GMT, Keith Thompson wrote: > On Mon, Jul 15, 2024 at 2:29 PM Alejandro Colomar <alx@xxxxxxxxxx> wrote: > > > This patch copies the description from POSIX > > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/memccpy.html > > > with the parameter names and added paragraph break retained from the > > > current version. The updated description is: > > > > > > The memccpy() function copies bytes from memory area src into > > > dest, stopping after the first occurrence of byte c (converted to an > > > unsigned char) > > > > I'd remove the parenthesis. That conversion is of course, no? For the > > standard, it makes sense to be pedantic, but for a user, I doubt the > > value of that statement. > > My personal preference is for the man page to be pedantic, but I'm > fine either way. The thing is, that detail is important to implementations. The user can pass a byte as a char, signed char, unsigned char, or an int, and all of them will work, so it doesn't really care what the function does internally. > > Especially with this function. My personal recommendation, after having > > researched so much about strings these last years, is that this function > > is useless (unless you're restricted to ISO C, and even then, it is, > > because you can write better functions as wrappers to ISO C functions). > > I've never used memccpy() myself. I suggest that the perceived > usefulness of a standardized function is not particularly relevant > to whether it should be documented. I agree that it should be well documented. And while I prefer all pages to be short, I think this one has more reasons. An obscure detail like that... hmmm, not sure. Let's keep it out, and if other readers think it is important, let's add it later. > > May I ask if you have any specific need for string handling? I'm > > developing a string library, libs, and I'm interested in feedback of > > possible users (for now, the targeted user is shadow utils). > > I became aware of this via this article: > https://nrk.neocities.org/articles/not-a-fan-of-strlcpy Hmm, interesting. Thanks! That article seems to use memccpy(3) as a home-made strtcpy() (and the interface it proposes as mystrcpy_trunc() is basically strtcpy(). inline ssize_t strtcpy(char *restrict d, const char *restrict s, size_t dsize) { bool trunc; size_t dlen, slen; slen = strnlen(s, dsize); trunc = (slen == dsize); dlen = slen - trunc; stpcpy(mempcpy(d, s, dlen), ""); if (trunc) { errno = E2BIG; return -1; } return dlen; } It can be written in terms of memccpy(3), but mempcpy(3)+strnlen(3) is faster, and to me also reads better, even if it's slightly more code. inline ssize_t strtcpy(char *restrict d, const char *restrict s, size_t dsize) { char *p; p = memccpy(d, s, '\0', dsize); if (p == NULL) { stpcpy(d + dsize - 1, ""); errno = E2BIG; return -1; } return p - d; } > linked from Hacker News: > https://news.ycombinator.com/item?id=40967069 > > I read the man page to learn about memccpy() and noticed the ambiguity, > then found that the POSIX description seems better. Thanks for that! > My interest is > improving the man page, not fixing a problem that affects me.. Good. > [...] > > > +.BR memccpy() > > > > Missing a space here before the (). > > Oops. > > [...] > > > > +bytes are copied, whichever > > > +comes first. > > > > Please break after the comma. > > I can produce a new patch if you like, or you can modify it as you > wish before applying it. Do you want me to produce a new patch? Nah, I'll amend it. Have a lovely night! Alex -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
