Fwd: Re: stpecpy(): A better string copy function

[Alejandro Colomar (man-pages)]

-------- Forwarded Message --------
Subject: Re: stpecpy(): A better string copy function (was: CHECKSTYLE:
Report consecutive .?P (paragraph macros))
Date: Sun, 13 Feb 2022 11:40:04 +1100
From: G. Branden Robinson <g.branden.robinson@gmail.com>
To: Alejandro Colomar (man-pages) <alx.manpages@gmail.com>

Hi, Alex!

At 2022-02-13T01:05:13+0100, Alejandro Colomar (man-pages) wrote:
> I designed some string copying function that attempts to improve
> strecopy(), and of course the common/standard ones, including
> strlcpy(3BSD) and strscpy(9), ....

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.)

Since stpcpy() resolves the issue that Mr. Chu was (rightfully)
aggrieved about, it might be regarded as "good enough" by most
conscientious practitioners.  (Unconscientious ones are plentiful, but I
don't expect anyone to pry them away from strcpy() and strcat().)

> char *
> stpecpy(char *dst, char *src, char *end)
> {
>       for (/* void */; dst <= end; dst++) {

Right away we see an assumption that the `dst` and `end` pointers are
comparable objects.  I'm teasing you a little, as there is no way in C
to express an assertion that they must be; it is up to the C language
runtime or the hardware to trap if this assumption does not hold.

But, _strictly_, you can't just go comparing pointers unless you know
they originate from the same underlying allocation region, however that
happens to be defined.

https://pvs-studio.com/en/blog/posts/cpp/0576/

I suspect, while admittedly having no evidence to offer, that this is
what has driven what success stpcpy() has had to date, and predict that
this is whence resistance to your stpecpy() proposal will arise, if any
does.

>               *dst = *src++;
>               if (!*dst)

As I've noted elsewhere (can't remember if it's where you might have
seen it), I dislike punning pointers to Booleans.  But this is a matter
of style, and as far as I know nothing can go wrong with it.

>                       return dst;
>       }
>       /* truncation detected */
>       *end = '\0';
>       return dst;
> }

Your logic seems to sound to me.  Only your assumptions give me
pause--and they are assumptions that most C programmers have most of the
time.  But see Yodaiken, "How ISO C became unusable for operating
systems development", PLOS '21[1].

My _guess_ is that people concerned about bounds issues are simply going
to use stpncpy(), ensuring control of the amount of copying, and not
relying on--or risking--the intervention of the runtime or hardware to
catch traversal outside the bounds of a memory arena.

I hope this helps, and please feel free to quote me elsewhere,
especially if you want to crash me up against real C experts and see how
well I fare.  ;-)

Regards,
Branden

[1]
https://www.yodaiken.com/2021/10/06/plos-2021-paper-how-iso-c-became-unusable-for-operating-system-development/