Microsoft To Banish Memcpy() 486
kyriacos notes that Microsoft will be adding memcpy() to its list of function calls banned under its secure development lifecycle. This reader asks, "I was wondering how advanced C/C++ programmers view this move. Do you find this having a negative impact on the flexibility of the language, and do you think it will restrict the creativity of the programmer?"
malloc() and free() (Score:5, Funny)
Python is done (Score:4, Funny)
Figures, Microsoft had to go kill of python and do it all in the name of security. No more accessing MEMory in C structures from our .PY files, damn it this really pisses me off.
First they take my gets.. (Score:5, Funny)
the worst offender is main() (Score:5, Funny)
Most any security problem can be traced back to this function.
"memmove()" is safer than "memcpy()". (Score:2, Funny)
As Windows products are now (and have been) mainstream products used extensively in banks and other financial institutions, reliability and security (RS) have prime importance. The speed that "memcpy()" gets you is not worth the price of reduced RS.
Re:A half-measure, at best... (Score:4, Funny)
So, Ben... or is it Peter? Do you always copy your comments verbatim from the linked article, or only when you agree with them?
Re:the worst offender is main() (Score:5, Funny)
you mean WinMain()
Re:First they take my gets.. (Score:5, Funny)
First they came for gets, And I didn't speak up because I didn't use gets
Then they came for scanf, And I didn't speak up because I didn't use scanf
Then they came for strcpy, And I didn't speak up because I didn't use strcpy
And then... they came for memcpy... And by that time there was no one left to speak up.
elevator firmware runs Windows? (Score:2, Funny)
Quit kicking a dead horse and just use Ada (Score:1, Funny)
Silly humans. Use Ada if you want to build something that works.
Re:No - there are plenty of safer alternatives (Score:4, Funny)
I'm not saying you can't get yourself into trouble with inappropriate use of memcpy(3), but buffer overruns aren't the go-to threat every time.
Didn't we already defeat the goto threat?
More to the point, if the developer doesn't know what memcpy does and how to use it correctly ... I mean ...
You might aswell write the 3 lines of code behind memcpy yourself.
The goto threat == Raptors (Score:4, Funny)
Re:malloc() and free() (Score:1, Funny)
The more they make C++ "safe", the more it becomes like Java. The more they make Java "powerful", the more it becomes like C++.
If you fix everything that is "wrong" in Java, you get C++. If you fix everything that is "wrong" in C++, you get Java.
Funny how that works. It's as if one tool cannot be everything to everyone.
Re:No - there are plenty of safer alternatives (Score:5, Funny)
Re:Silly and useless (Score:3, Funny)
ouch.
Ban = operator also (Score:3, Funny)
If a developer can't do "if (sizetocopy = sizeofdstbuffer)"
Uh oh, we'd better ban the = operator too, so no one can mistake it for == in an if statement ever again.
Re:Good. (Score:3, Funny)
Yes and yes. I've been a developer for over 30 years now(nearly all C or C++). How about you?