Re: Once again
such as using strcpy() with no idea if the source string is larger than the destination buffer. There exists a call in the standard library - strncpy() so this bug should never happen
Except that strncpy() has fundamentally broken semantics, and cannot be used safely for its intended purpose unless you already know the source string fits in the destination (in which case strcpy is suitable and should perform better) or explicitly terminate the destination after copying (in which case you have an additional step to perform after the call, creating another opportunity for programmer error, and you may be unnecessarily touching a page).
strncat() has the correct semantics - it always terminates the destination provided the copy length is at least 1 - but to use it as a safer strcpy you have to initialize the first byte of the destination (and to use it as a safer strcat you have to understand the semantics of the length parameter, which many people get wrong).
Thinking that strncpy is ever the right answer, regardless of what your problem is, is a perfect example of the dangers of C. The C standard library has a number of traps for the unwary. (The %n format specifier for the printf family is another example.) In its defense, at least the C specification is short enough to be read and understood by most C programmers, which certainly can't be said for the ponderous tome that is the C++ standard.
(Richard Heathfield, longtime regular of comp.lang.c, was of the opinion that the strn* functions were undesirable anyway. In his view, you always need to know whether the source fits in the destination, so you can perform proper error handling; silently truncating the string is just lazy programming. And if you already know both lengths, you might as well use memcpy and save a few cycles.)
It is possible to write good C code. It is unfortunately very difficult to do so, and many of the people who think they can do not, in fact, understand the language well enough.