No You Can’t Use That Feature

I am actually old enough to remember when Edsger Dijkstra's letter Go To Statement Considered Harmful was a key influencer in the move to structured programming. My professors all taught that the Go To statement was bad and it was effectively banned from use in our course work. That was a lesson I carried with me for decades and something I taught to my students as well. In general I think that was a good thing. it did lead to a lot of discussions over the years but I think those discussions were a good, perhaps essential part of the learning experience. In the long run it is good when students challenge teachers to answer more completely than “because I say so” or “just because.”

Today program safety and security has become more important than ever before. Companies that are looking to make their code better where better means things like reliable, safe, maintainable and secure are taking close looks at where problems occur. And they are creating rules (or at least strong guidelines) to try to avoid the most common problems. in that context Microsoft just announced that they are banning memcpy() from use. Memcpy() copies some number of bytes from one memory area to another. Unfortunately if you make a little tiny mistake this function will happily copy memory where you don’t want it to go. Whoops! Microsoft is replacing memcpy() with memcpy_s() which requires additional parameters in hopes that being more explicit about things will make things safer.

So what does this mean for educators? Well if you are only teaching “safe” languages or “managed code” languages like C#, VB or Java perhaps not much. but at some point real computer science students have to know about memory management and that is where issues like this come up. If you are teaching C or C++ it will come up sooner rather than later. I think there are some good lessons here though for everyone doing software development. It just might be worth a discussion in class even if you are not using C/C++.

BTW You can read all about sending memcpy() to the SDL Rogues Gallery at the Software Development Lifecycle blog. For more information about this sort of thing there is an earlier post titled Good hygiene and Banned APIs. For a list of  SDL banned function calls take a look here.

Bonus note: I see that MS Learning is offering The Practical Guide to Defect Prevention as a free download book for a limited time only.

Comments

• Anonymous
  May 20, 2009
  I can clearly remember the "don't ever use goto" class.  I believe it was way back in intro to VB.  Good times.

• Anonymous
  May 20, 2009
  The comment has been removed

• Anonymous
  May 20, 2009
  While I do agree that the memcpy() function is "dangerous" when used incorrectly, simply banning it from the API is not the best course of action. I believe that the best way to discourage poor use of features is by teaching it properly. While Goto is a horrible statement and should never be touched, I still believe that people should be taught Goto and why structuring a program is better. With the advent of Managed Languages in recent years, students have had to learn less and less about memory management and safe programming techniques. A curriculum should cover functions like memcpy(), strcpy(), and all other data manipulation functions. Teach the student how to use the functions and why it is unsafe, and make sure you drill it into their skulls how important it is to use them correctly. -Patrick Godwin