原文地址：http://www.theregister.co.uk/2009/05/15/microsoft_banishes_memcpy/

Memcpy() and brethren, your days are numbered. At least in development shops that aspire to secure coding.

Microsoft plans to formally banish the popular programming function that's been responsible for an untold number of security vulnerabilities over the years, not just in Windows but in countless other applications based on the C language. Effective later this year, Microsoft will add memcpy(), CopyMemory(), and RtlCopyMemory() to its list of function calls banned under its secure development lifecycle.

Memcpy has long served as a basic staple of C-based languages, providing a simple way to copy the contents from one chunk of memory to another. Its drawback comes when the source to be copied contains more bytes than its destination, creating overflows that present attackers with opportunities to remotely execute code in the underlying application.

"That's definitely one of those notoriously dangerous C commands," said Johannes Ullrich, CTO of the SANS Institute, who teaches secure coding classes to developers. He likened memcpy() to other risky functions such as strcpy() and strcat(), which Microsoft has already banned after exacting untold misery over the years.

Developers who want to be SDL compliant will instead have to replace memcpy() functions with memcpy_s, a newer command that takes an additional parameter delineating the size of the destination buffer. The command is already supported in Microsoft's Visual C++, but according to Ullrich, native support doesn't yet seem to be available in the GCC compiler. (This evidently can easily be worked around, according to this discussion. Readers who know other approaches are encouraged to leave a comment.)

A Microsoft blog entry that heralded the planned change suggests modifying common header files so compilers issue a warning each time the banned function is used.

It also wondered aloud when "Larry, Steve, and Linus" plan to issue similar security edicts in their products. It's a question worth asking. ®