that sounds misleading. the white paper states that "for example, using strncpy " is a good security practice"
even though strncpy and strncat are actually used incorrectly MUCH MORE OFTEN than strcpy.
Let me explain. People that use strcpy tend to use malloc()ed memory because they know how it works, and that they have to supply a certain size before they copy in it.
However, almost nobody knows how strncpy works. (as for strncat, i don't recall seeing it correctly used)
i wouldn't call that "safe", i see most strncpy uses as "oh well there's probably an off-by-one there". (i'm not pushing for strcpy() use, it's horrible, i'm pushing for strlcpy() use, with which you know you understand the API, and you can detect truncation easily. google for the paper, and the stupid gnulibc objections)
Slashdot Mirror
and you think you understand strncat?
i hope you reread the manpage and its implementation before going to bed, or you're probably just sticking your finger in your eye. real deep.
that sounds misleading. the white paper states that "for example, using strncpy " is a good security practice"
even though strncpy and strncat are actually used incorrectly MUCH MORE OFTEN than strcpy.
Let me explain. People that use strcpy tend to use malloc()ed memory because they
know how it works, and that they have to supply a certain size before they copy in it.
However, almost nobody knows how strncpy works. (as for strncat, i don't recall seeing it correctly used)
i wouldn't call that "safe", i see most strncpy uses as "oh well there's probably an off-by-one there". (i'm not pushing for strcpy() use, it's horrible, i'm pushing for strlcpy() use, with which you know you understand the API, and you can detect truncation easily. google for the paper, and the stupid gnulibc objections)