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.