On Mon, Jul 15, 2024 at 2:29 PM Alejandro Colomar <alx@xxxxxxxxxx> wrote: > > Hi Keith! > > On Mon, Jul 15, 2024 at 02:14:23PM GMT, Keith Thompson wrote: > > The current description in the memccpy.3 man page: > > > > The memccpy() function copies no more than n bytes from memory > > area src to memory area dest, stopping when the character c is found. > > > > If the memory areas overlap, the results are undefined. > > > > doesn't clearly say whether the final character c is copied or not. (It is.) > > Agree. It is implied by the RETURN VALUE section, but the description > didn't say it (and the RETURN VALUE only implied it). > > > 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. > 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. > 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 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. My interest is improving the man page, not fixing a problem that affects me.. [...] > > +.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?