Re: strscpy

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    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.

kre