Re: memccpy(3) and stpcpy(3) status in C2x (was: stpecpy(): A better string copy function)

[Martin Sebor]

On 2/13/22 13:32, Alejandro Colomar (man-pages) wrote:
> Hi Branden,
>
> On 2/13/22 19:29, Alejandro Colomar (man-pages) wrote:
> > > Oh, I was going to ask if you were aware of stpcpy(), but if I click the
> > > link to codidact I see that you are.
> > >
> > > I expect/hope stpcpy to become the new norm for string copying, though
> > > it will require overcoming much inertia and many dusty old books.
> > >
> > > It was introduced to POSIX in Issue 7 (2018).
> > >
> > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/strcpy.html
> > >
> > > Martin Sebor is sponsoring its inclusion in C2x.
> > >
> > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2352.htm
> > >
> > > (It may have been accepted, or not--I haven't checked the status.)
> >
> > No, stpcpy(3) was not accepted.  memccpy(3) was instead.  The problem
> > wasn't stpcpy(3) as it seems, but stpncpy(3) about which I'll rant a bit
> > below :).
>
> I forgot to link to the C2x document, which contains very interesting
> information:
>
> <http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2349.htm>
>
> TL;DR: That document considers strlcpy(3) to be "optimal", but not
> widely supported enough, and then selects memccpy(3) as "good enough"
> and way more widespread.

I think that was also the sentiment in WG14 when the proposal was
discussed.  N2352 proposed stpcpy and stpncpy by themselves but it
didn't gain enough support.  More detail of the committee discussion
of both proposals (and others) is in the meeting minutes:
  http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2376.pdf

Martin

> Cheers,
>
> Alex