So, read any good buffer-overrun articles lately? Notice how they like to show the hapless programmer cheerfully using strcpy() to copy 11 characters (or 11,000 maybe) starting at the location where only 10 characters worth of space was allocated? Or maybe it's strcat that, merrily continuing till it finds that null terminator in the source string, goes way past its boundaries. Did you ever think to yourself as you read these examples, “Why can't strcpy, strcat, and the rest of them save stupid programmers from themselves?” (It's ourselves, really, but we all suffer from a little denial that we could ever write that sort of code.)

That's an idea, let's replace the naive and trusting version of strcpy, that assumes no-one ever gives it inappropriate arguments, with another version that doesn't always do as it's asked! Why not? I'll tell you why not: this is C++. And if C++ had a motto, it would be “you're the programmer!” or as I sometimes say, “OK, it's your foot!” Seriously, changing the way strcpy behaves might break code that isn't broken or insecure right now. In C++, we're allowed to write code that some compilers wouldn't let us write.

And if you were going to rewrite things, you might like to change the signature anyway, so that you could return an error code or other information. That means what you really need is a replacement for strcpy (and the rest) that's a little safer. And maybe to have the compiler warn you on your calls to strcpy so you can go through by hand and switch to these safer ones case-by-case.

That sounds like a plan. And I don't even have to do it. It's coming in the updated versions of the C Runtime Library for Whid-- er, Visual Studio 2005. And while they're at it, they're adding some overrun protection to the STL in the same timeframe. Intrigued? Read the whitepaper on MSDN. Michael Howard, coauthor of  Writing Secure Code,  lays out some of the problems and how the secure versions of old CRT standbys can keep your code out of hot water.