Re: strlcpy() notes (was Re: [GIT PULL] smb3 client fixes)

[Ingo Molnar <mingo@kernel.org>]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> So I despise strlcpy(), but I think strscpy() is kind of broken too.
> For the generic case, it really should have two separate buffer sizes.
> 
>  (2) if you expect the destination buffer contents to be untouched
> past the terminating NUL character, you're simply out of luck
> 
> The strscpy() assumption is that it can arbitrarily write to the
> destination buffer.
> 
> So the best way to think of "strscpy()" is really as a "optimized
> memcpy for strings". That's almost exactly how it acts. It will do a
> memcpy(), but stop when it notices that it has copied a NUL character.

Not to shed-paint this too much, but would it help if the naming reflected 
that property of chunk-size NUL-(over)write a bit better?

- memcpy_str(), memstrcpy(), memscpy(), etc.?

Developers do tend to think differently about operations that are named 
after memcpy(). Here the argument order and semantics are pretty close to 
memcpy() - if the naming is similar, we'd want people to think of it as a 
memcpy(), not a string-copy.

[ Personally I'd prefer memcpy_str(): it's a variant of memcpy() that stops 
  earlier if possible, and does the 'early stop' safely & robustly. ]

Thanks,

	Ingo