Re: strscpy

Le 20/05/2020 à 00:22, Robert Elz a écrit :
>      Date:        Tue, 19 May 2020 19:15:46 +0200
>      From:        Maxime Villard <[email protected]>
>      Message-ID:  <[email protected]>
> 
>    | I see no reason to want to have a string copy function able
>    | to copy a terabyte worth of string in the kernel
> 
> No, of course not.   My point was that you're touting this function as
> being near perfect - and it isn't.

I didn't say it is perfect or near perfect. Quoting myself:

	"What I find nice with strscpy(), is that it simply corrects the
	 unsafe strlen behavior of strlcpy(), but preserves the pattern
	 of arguments. [...] strscpy() seems like a good balance to me."

>    | Also, FYI, there is a difference between source ASM language
> 
> which is what I meant .. string functions tend to be important enough
> (and simple enough) that writing them in assembler can bring large
> gains ...

Actually, no:

	https://mail-index.netbsd.org/port-amd64/2020/04/19/msg003228.html

> Is there really some great difficulty in just using copystr() more ?

There apparently is. Which can be understood, because people reuse the
functions they know well.

I think it matters to have a function that preserves the pattern of
arguments of the libc strlcpy(), strncpy(), memcpy() and memset(). That
is: (dst, src, len).

I still don't quite get why overloading is such a big deal, considering
that 99% of the callers aren't interested in the return value to begin
with. There also is plenty of overloading all over the kernel and libc,
because that's convenient, and C doesn't support tuples as return
values.

In short, I would entirely dismiss your point.

Maxime