Slashdot Mirror

← Back to Stories (view on slashdot.org)

Microsoft To Banish Memcpy()

Posted by kdawson on from the good-riddance dept.

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?"

17 of 486 comments (clear)

  1. malloc() and free() by Anonymous Coward · · Score: 5, Funny

    Those are also dangerous functions. And also array indexing! That should also be eliminated.

    1. Re:malloc() and free() by Anonymous Coward · · 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.

  2. Python is done by sunami · · Score: 3, 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.

  3. First they take my gets.. by adonoman · · Score: 5, Funny

    First they came for gets, then they took scanf and strcpy, now they want memcpy? Outrageous! How are virus writers going to be able to take advantage of buffer overflows if I'm continuously keeping track of how big my buffers are? I may have to start lying about their size just to give hackers a chance.

    1. Re:First they take my gets.. by Anonymous Coward · · 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.

  4. the worst offender is main() by JeanBaptiste · · Score: 5, Funny

    Most any security problem can be traced back to this function.

    1. Re:the worst offender is main() by Khashishi · · Score: 4, Funny

      you mean WinMain()

  5. "memmove()" is safer than "memcpy()". by reporter · · Score: 2, Funny
    Though "memcpy()" is slightly faster than "memmove()", the latter is safer.

    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.

  6. Re:A half-measure, at best... by wampus · · Score: 3, 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?

  7. elevator firmware runs Windows? by Gary+W.+Longsine · · Score: 1, Funny

    Oh, stars above, what have we done...

    --
    If you mod me down, I shall become more powerful than you could possibly imagine.
  8. Quit kicking a dead horse and just use Ada by Anonymous Coward · · Score: 1, Funny

    Silly humans. Use Ada if you want to build something that works.

  9. Re:No - there are plenty of safer alternatives by buchner.johannes · · Score: 3, 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.

    --
    NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
  10. The goto threat == Raptors by beathach · · Score: 4, Funny

    Foolish mammal, they cannot be defeated so easily. http://xkcd.com/292/

  11. Re:No - there are plenty of safer alternatives by James+Skarzinskas · · Score: 5, Funny

    In an effort to "one-up" Microsoft, Apple promises to replace their own memcpy() with one that not only does not require a size for the destination buffer, but does not require a destination buffer at all. While Apple programmers call the move "totally pointless" and "absolute proof of functional retardation", Steve Jobs has simply responded, sagely, that the future of Apple development is through so-called "intuitive APIs". It just works.

  12. Re:Silly and useless by harry666t · · Score: 2, Funny

    > if (sizetocopy = sizeofdstbuffer)

    ouch.

  13. Ban = operator also by Safiire+Arrowny · · Score: 2, 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.

  14. Re:Good. by JustNiz · · Score: 2, Funny

    Yes and yes. I've been a developer for over 30 years now(nearly all C or C++). How about you?