Re: strscpy

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 30/05/2020 à 14:33, Robert Elz a écrit :
>      Date:        Sat, 30 May 2020 08:52:39 +0200
>      From:        Maxime Villard <max%m00nbsd.net@localhost>
>      Message-ID:  <f3a968bb-5e34-12bf-cd3f-1f0813d2dbea%m00nbsd.net@localhost>
>
>    | Correct, but please keep in mind that the goal is also to replace
>    | copystr(), and there are a few (<10) cases where the caller wants
>    | the len.
>
> I'm not sure that it is worth replacing copystr() - it seems to have
> no issues (which is one reason why using it as the replacement seems
> like a suitable way to go to me).
>
> But assuming that isn't the plan, another method might be to have
> the new function (not called strscpy() as that would just cause
> confusion -- and make it easy to accidentally include code that assumes
> that function works as in its native form) return a size_t and have
> the error indication be "len + 1" instead of -1.
>
> That removes the overloading of the result - all that is returned is
> the length - returning a value larger than the buffer size indicates that
> the input string was too long (but unlike strlcpy() there would not be
> any kind of attempt to indicate how big the buffer ought to be).
>
> Callers that know there is no problem (that there cannot be) and don't
> check the result would work, code that wants to check for errors would be
> slightly more costly
>
> 	if (new_function(dst, src, len) > len)
> 		panic("apocalypse now"):
>
> but not significantly so, and code that actually wants the length gets it,
> and what's more, gets it as a size_t so no cast is required to pass it to
> other functions which expect size_t rather than ssize_t.

Sounds like a good compromise. Let's go with that.

Now we need to decide how to name the function. We could use strkcpy(),
k for kernel; there are no matches against other open source kernels of
interest (as can be seen on src.illumos.org), and no relevant hits on
Google.

k is the best unused letter I can think of, the rest is overcrowded,
because as far as Google indicates, many random libraries re-implement
their own string copy functions and use the other letters.

Or we could accept some conflict and opt for a sober strxcpy(); no
matches against other kernels again, however there are hits on Google.

Maxime