I recently stumbled across an article that claims Microsoft is banning the memcpy()
function in its secure programming shops. I understand the vulnerabilities i
Is banning memcpy() in my code making me a better programmer and my application safer or just more incompatible? I'm uncertain, if MS really wants to change anything or just make any new C code incompatible with other compilers. Btw. MS does this trick on many functions and it's quite annoying. strcpy -> strcpy_s -> StringCchCopy.
You are supposed to use memcpy_s() instead. The same kind of _s versions exist for a variety of other functions considered as unsecure.
Don't bother. Microsofts alternatives are not that much better. The main value is that these cause your code to become unportable to Linux. Microsoft is making much more money on the OS they sell to your customers than they're making on the copy of Visual C++ you bought.
You said it yourself: "Microsoft is banning the memcpy() function in its secure programming shops, I understand the vulnerabilities inherent in the function,"
memcpy() and a plethora of other standard functions are known to cause vulnerabilities, so why would a secure programming shop allow their use when an (albeit incremental) improvement is trivial?
No doubt in their efforts to improve the security of their own products, the code reviews clearly indicated that these functions were responsible for a significant proportion of vulnerabilities, buffer overflows etc. Rather than make wrappers for internal use only they introduced them into the standard library and added a compiler warning (not a ban) for the benefit of all.
A chainsaw, if used properly, is safe. Same thing with memcpy(). But in both cases, if you hit a nail, it can fly and hurt you.
In short, memcpy() is required for low-level computing and won't go away, but for high-level programming you don't need it. There is no memcpy() in Python.
If you're using older versions, like C99 or C++98, or on Solaris, you can't use memcpy_s, unless you have the Safe C library installed.
memcpy_s() is a Microsoft-specific implementation that doesn't exist on non-MS implementations, including ANSI, prior to C11, per their own standards.
I'll leave the pro-MS and anti-MS stuff aside, because it's irrelevant.
memmove() is a better solution anyway since it addressed the overlap issue. memmove_s() is more robust, but again, only if you're in C11 or later.