Messages in this thread | | | Date | Sun, 21 Aug 2022 23:40:18 +0200 | From | Ingo Molnar <> | Subject | Re: strlcpy() notes (was Re: [GIT PULL] smb3 client fixes) |
| |
* 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
| |