* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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
