[ploxiln]

strcpy() - sure it is fairly often used unsafely, strlcpy() or snprintf() or similar should generally be used. But memcpy()? It takes an explicit length, which you have to calculate. What's the alternative? memcpy_s() does part of the check for you, but you end up writing more code around it. It's trying too hard and not achieving a net positive. I have seen "use of unsafe function memcpy()" show up in some dumb security scans recently, and it's a strange development. There is lots of C code where avoiding memcpy() would be quite awkward and really not help anything at all, it's just a fundamental operation.

Here's a dry technical report on how the new-ish _s variants are not really helpful: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm

[rurban]

This technical report is nonsensical, and asks for continuation of widespread insecure practices. The authors (the glibc maintainer) should be removed from the committee for spreading such harm. He simply doesn't like secure practices, and continue to use sometimes checked calls. If he would have some technical competence he would implement the needed safety checks seperated into compile-time (no performance penalty) and runtime (when the compiler doesn't know). He only does the first, and leaves all the dynamic cases unchecked. But then he would stumble over the inability of gcc to properly handle compile-time expressions.

See eg. https://rurban.github.io/safeclib/doc/safec-3.5/index.html

[trickstra]

But is the use of strcpy and memcpy worthy of a global boycott and witch-hunt?