They're at it again
In 2005, I expressed my concerns regarding the spurious "deprecated" warning of Microsoft's Visual Studio 2005. Three years later, they're at it again. Visual C++ 9.0, which is the C++ compiler underneath VS 2008 Pro Beta Release Candidate (made available last fall) is still generating the same annoying and misleading warning. Microsoft's ulterior motives explain why this false alarm has never been fixed. The costs of this false alarm are significant, and call for a drastic response from the C++ community, once and for all.
Back in 2005, the outrage elicited inconsistent responses from Microsoft officials. Those responses included the following points:
- Enabling these warning by default was an "accident"
- Microsoft will consider replacing the word "deprecated" with a different adjective.
- The allegedly safer functions (e.g., sprintf_s) are about to be standardized, so in the long term, the use of the "safer" functions should not cause portability issues.
- Most importantly: the recommended replacement functions are safe.
As if 3 years hadn't passed, a couple of days ago a loyal reader informed me that VS 2008 Pro Beta Release Candidate (made available last fall) is still generating the same annoying and misleading warning when compiling a program that calls sprintf:
warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
Playing with Words
Indeed, the original warning was modified cosmetically, so as to give you the impression that Microsoft fulfilled its promise in item #2. But let's look at it the broader context and see what's really going on here.
While the tem "deprecated" was substituted for "unsafe" in the first sentence of the warning message, "deprecation" re-emerges in the second sentence. I find it hard to believe that this is just the result of sloppy proofreading. Rather, my impression is that Microsoft is clinging to this scary root (deprecate) on purpose.
Safe? Try "False Positive" Instead
In my former diatribe against the spurious deprecated warning I proved that so-called safe versions of the standard functions aren't really safe. sprintf checks its buffer's upper bounds, but it doesn't check its lower bounds, which leaves the program vulnerable to buffer manipulations that could cause a deliberate crash (this is a common trick that crackers use to get a command line prompt). This can be fixed, but who'd want to use a function that spends more than 90% of its CPU time checking upper and lower bounds?
The Standardization That Never Took Place
The promise to standardize the so-called safe functions has not been fulfilled. Just as C++/CLI hasn't been approved as an ISO standard (there are other examples of Microsoft's failed attempts to rubberstamp its proprietary implementations with an ISO hallmark), the so-called safer library functions have remained Microsoft proprietary.
Why Disabling Warning 4996 Won't Do
Seemingly, the solution is to disable warning C4996. The problem is that project managers will rarely agree do that. In many projects, compiler warnings are treated as errors; a clean build session must end with zero warnings. Furthermore, in such projects, compilers are explicitly tuned to the highest warning level.
Microsoft's Ulterior Motives
What I've said thus far doesn't explain Microsoft's ulterior motives. I'll be blunt and risk cranky emails from Microsoft's PR department: I believe that the real motive for this deliberate annoyance is to leave programmers no choice but to switch (sorry, "migrate") to Microsoft's proprietary functions, thereby confining their code to Windows exclusively -- or at least making portability much more difficult.
Microsoft's insistence on using the term "deprecated" in all of its inflections and derivations deserves an explanation, too. They're doing this because they know that in the collective mind of the C++ community, the term "deprecated" has a very alarming meaning. A deprecated feature is one that the standards committee denounces; deprecating a feature is the last step before removing that feature from future versions of the standard. Deprecation often is the result of serious flaws, obsolescence or incompatibilities with other language features. Just to give you a clue on the severity with which the standards committee regards deprecation, the infamous auto_ptr, which is incompatible with Standard Library algorithms and containers, is NOT deprecated. A well-deserved deprecation is manifested in vector<bool>, which is unquestionably one of the biggest gaffes of the standards committee (and I'm not saying it to criticize anyone) Thus, when Joe Coder or his boss see a warning message that blurts "deprecated" at them, they are almost compelled to do one thing: a wholesale replacement of perfectly legal, standard, efficient and portable functions, with Microsoft's proprietary functions that are slower, not necessarily safer, and certainly non-portable.
Speaking of Safety
It's time to kill another myth. There's nothing inherently less safe in sprintf than any other standard C++ feature. Take std::vector for example. I can easily show you a dozen of memory-related bugs that improper vector usage could cause. Surprisingly, these bugs and others (which can be easily detected by the compiler), do not generate any warnings:
using namespace std;
vector<auto_ptr<int> > vi;
vector<auto_ptr<int> >::iterator it=vi.begin();
Make no mistake: every line of the four code statements in main() is an abomination. You won’t be able to run this program without crashing. And yet, Visual Studio 2005 Express Edition doesn't utter a single warning:
myproje - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
"OK, he must have used warning level 3", you're probably thinking. Actually, I used warning level 4 (the most pedantic level)!
Compiling the same program with VS 2008 resulted in a compilation error regarding the allegedly missing assignment operator of auto_ptr, but the rest compiled just fine (I'd like to thank Martin Goff for his assistance with these tests).
In conclusion, Microsoft doesn't really care about your code safety. Under the sanctimonious appearance of code safety concerns, they're trying to use questionable means for locking users in.
In 2005, I was naive enough to believe that the pressure from the C++ community would force Microsoft to behave properly. Today, the only solutoin I see is in the form of a class action against Microsoft. We can analyze the etymology of "deprecated" for three more years, but the bottom line is this: Microsoft's unfair tricks cost you big bucks. Every project manager who has to allot additional human resources for "fixing" perfectly valid code will tell you how expensive such a spurious warning is. Every programmer who had to stay long hours at the office locating every occurrence of an "unsafe" function would be glad to send the bill to Redmond, as would any QA team leader. It's time to speak the only language Microsoft speaks and understands: the language of a class action, court orders, fines and regulators. Any volunteers from the European union?