Re: strscpy
Maxime Villard <[email protected]> Sat, 30 May 2020 16:39:46 +0200
| Newsgroups | gmane.os.netbsd.devel.security |
|---|---|
| Message-ID | <[email protected]> |
Le 30/05/2020 à 14:33, Robert Elz a écrit : > Date: Sat, 30 May 2020 08:52:39 +0200 > From: Maxime Villard <[email protected]> > Message-ID: <[email protected]> > > | 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