Martyn Lovell wrote:
Hi everyone,
I wanted to take a few moments to address the range of points raised in this thread, and to provide a little background.
Herb provided a great summary of our motivations here. We want to help developers write more secure code, and we want to do that by default, so that the out-of-the-box experience is as secure as we can make it. We've reviewed lots of code in the last few years as part of the intensive security focus at Microsoft. Though we've already used these lessons to secure our own code, we wanted to help them be applied to other code too.
To make this happen, we added "deprecation" warnings to a bunch of standard APIs. Most warnings tell you what function to use instead. For example, the warning for strcpy will point you at strcpy_s, which takes a buffer size as a second parameter. As you can imagine these kinds of changes mostly impact the C standard library.
I haven't looked at VC8 for a while, but last time I looked, the deprecation warnings were entirely useless for one simple reason: a single "deprecated" warning was used for gets, strcpy, and fopen (!). The only thing this deprecation campaign achieves is to de-value the warning and make the decision to turn it off a no-brainer. A more sensible approach would be to define a new class of "deprecated for security reasons" warnings. "Guaranteed buffer overflow", "potential buffer overflow" and "overflow-safe with potential subtle security implications" should be separate warnings that can be switched on/off independently. The choice between portable but "deprecated" and non-portable but secure isn't very appealing either, but that's a separate issue. I'd prefer the undeprecated version of sprintf to be snprintf instead of sprintf_s, and the undeprecated version of swprintf to be swprintf (the standard version of which wasn't insecure, only the Microsoft nonstandard variation was.)