Re: strscpy

Unfortunately, that function overloads the return value with the
error indicator, which means it has to be ssize_t rather than size_t,
which means that half the strings that it is able to copy can't be
handled because there's no way to return the result properly.

And yes, I know, the chances of anyone ever wanting to copy a string
that is longer than what can be represented in a ssize_t are slim,
but given that someone is going to the trouble to design a new
interface, they really should avoid stupid design limitations.

It looks to be as if copystr() is a much better interface, not only
do we already have it, without design flaws like that one has, but
it also has the args in the sane (bcopy) order rather than backwards.

kre

ps: wrt     implemented in ASM which annoys sanitizers that need
	    wrappers as a result.
Any string function in the kernel (or even in userland) - or at least any
which isn't optimised aaway by the compiler, is likely to be implemented
in assembler on many architectures.   There's no reason strscpy() would be
different.