

Linus Torvalds: Re: revert “fs/befs/linuxvfs.c: replace strncpy by strlcpy” - bootload
https://lkml.org/lkml/2015/4/28/570

======
whoopdedo
strncpy is my least favorite C function. Not terminating with NULL when the
destination length is exhausted is bad enough. But when you give it a large
enough buffer, it wastes cycles padding the destination with NULLs to the full
length. If that's what I wanted I'd have just called memset ahead of time!

I ended up getting in the (probably bad) habit of using strlen+memcpy for all
my string management needs. That is, until I realized I shouldn't be wasting
my time with such tedious bit-twiddling and moved on to C++ with std::string.

~~~
jomar
strncpy()'s NUL-padding behaviour is the right thing for its niche, which is
copying to fixed-length buffers such as the 14-character filenames in ancient
filesystem directory entries. See
[http://stackoverflow.com/a/1454071](http://stackoverflow.com/a/1454071)

That niche doesn't particularly exist anymore, so strncpy() isn't often a good
fit for what people need these days. Hence they don't like strncpy(), but what
they really mean is that they shouldn't have been considering strncpy() in the
first place.

strncat() on the other hand... now that's a weird function!

