microsoft banished memcpy

[Chinmoy]

This screenshot shows a wall hack made in COD2 with memcpy().
Microsoft has decided to ban another buffer manipulating function. This time it is memcpy(). Long after banning dubious security vulnerabilities like strcpy(), strcat(), strncpy(), strncat(), gets(), microcoft has finally decided to ban the memcpy() function and place it in the C and C++ recommended banned API list with a confirmation of ban from inside sources.

The function memcpy has a syntax ::

1.
void *memcpy(void *destination, const void *source, size_t num);

This function copies num bytes starting from source to destination. It does not cause any overflow, returns s1 and has full portability.
Easily guess wherefrom C derives it’s memory powers from!!

This ban has a direct impact on DirectX, Outlook Express, Messenger, Pnp, Help and support and many
others microsoft bundled applications and services.

Although many suggest memcpy_s() as an alternative, i do not see any difference in using it as we can still get the buffer size wrong and create havoc. Also, memcpy_s() is not GCC compliant.

This will also cause programs application developers for windows to amend their codes if they want to remain SDL compliant.
Read the complete article here :: microsoft banished memcpy | TECHARRAZ

[WingedPanther]

Here's the real problem, as I see it: It's part of the C and C++ languages!

You can "ban" a function all you want, but then MS won't be able to create a standards compliant compiler for C or C++. This isn't a "feature", it's core functionality of many low-level languages. What MS should be doing is working on is a better method for keeping processes secure from each other. This sounds like a lame attempt at "security".

[Chinmoy]

But then the memcpy function is a mess as it can cause buffer overruns. Am i missing something? I guess there are a lot of things MS should do starting with a better open compiler but doing away with exploitable codes is always welcome!

[WingedPanther]

Well, since I don't use MS compilers, I don't have an issue with that. The simple reality is that if their compiler breaks legacy C code, they will have problems doing basic things like compiling Windows.

[Jordan]

Figures. I don't understand why MS thinks they can "ban" something from a standard they do not maintain.

Nice post, Chinmoy.

[Termana]

I like how the blog post was quoted right up until the last paragraph - this way it looks like the post was bashing microsoft. Read on and you find this:

Two other functions lined up in the ban are copyMemory() and RtlCopyMemory(). This is a good move by Microsoft as these buffer and memory manipulation functions are of more abuse than use.

In context, the blog is speaking how this will be a good thing, even though, Chinmoy, you try and make it look like its saying its a bad thing.
Also - the ban, they aren't trying to modify the standard. SDL (Security Development Lifecycle) is its own standard used for implementing security into applications. No one says you have to be SDL compliant. Microsoft will probably be taking the biggest hit from this since they will be updating their software to comply with their own standard (or maybe not... lol, but hell thats a whole other post).
I guess some people stop at no ends to bash Microsoft. Nothing personal Chinmoy

[Chinmoy]

Well, you gt me all wrong my friend. I did not mean any microsoft bashing! I am no fan of microsoft but this move, i welcome it. Just that it came too slow. Should have probably done right away along with strcpy(), gets() and alikes. I really appreciate what microsoft has done with this :: techarraz-PROGRAMMING AND TECHNOLOGY

[Chinmoy]

thanks jordan.