Re: Ambiguity in memccpy() description, with patch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?





[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux