Bronek Kozicki wrote:
Jonathan Turkanis wrote:
It would probably be a good idea if someone would volunteer to give
Microsoft's headers a once over and see if there are any other API's
that are needlessly deprecated. Certainly there plenty of room for
frustration here - I've seen deprecated warning from std::copy and
other std lib algorithms (and no *not* using pointers), as well as
the C API's.
Maybe they should just deprecate everything, to be on the safe side.
starting with cash cows ... errr ... Windows and Office?
Sorry for harsh tone, but I started getting unpleasant feeling that my
favourite compiler will soon completly "deprecate" well established
and very portable C++ library "just to be on the safe side", while
real bugs are hiding somewhere else. Maybe Microsoft programmers do
need some special, crippled library to help them write secure code,
but forcing it down the throat of all their customers is bit too far,
IMO. MSVC8 is "deprecating" std::copy !? Maybe all std algorithms, eh?
And BTW, I thought that term "deprecated library features" is actually
used by the
C++ standard, has clear meaning, and using it to describe some other
kind of "depreciation" in the context of the C++ library
implementation is little misleading.
Thanks for the cc:, Bronek. I've passed this on to Martyn Lovell, our libraries lead, who can reply in more detail. Short answer: I haven't looked at your use in detail, but apart from suppressing the warning (which I can imagine you wouldn't want to do in your headers) maybe a realistic option could be to use checked iterators when compiling for VC8. If that's an option, presumably that would not only suppress the warnings, but also make your code safer...? I don't know if there might be issues with mixing libraries built using checked iterators with ones built with unchecked iterators, etc., but if you're interested in this path then Martyn could help point you in the right direction. Longer answer: Fortunately, it's not as bad as the above. We are not removing *any* ISO C or C++ features from our compiler or libraries. Period. Here "deprecated" doesn't mean anything w.r.t. ISO C++ conformance or about potentially removing anything. I'm sorry that the word "deprecated" is a bit confusing, but I can share some history and that we're trying to improve the wording. Like every compiler, VC++ has a "deprecation" mechanism we use to generate compiler warnings (not errors) to a) encourage users to consider using alternatives or b) warn users that the feature might be taken away altogether. Of course, usually compilers deprecate their own extensions, not standard APIs. How we got here: In the course of the security scrub work, we identified potentially unsafe APIs in our entire product, including our own extensions as well as standard (C or C++) features. Most of the standard ones were in the C standard library; we offered them to ISO WG14 (C), who showed interest and is now processing them as the Safe C Standard Library Technical Report (with changes, and we are applying the committee's changes, and community feedback changes, in our product); see WG14 website for the latest drafts. So most of the affected standard APIs were in C, but some were in C++. To warn users that APIs might be unsafe, it was convenient to (re)use the existing #pragma deprecated mechanism, and that could me a little misleading for the standard APIs -- we are definitely not removing any of those standard APIs, but we are pointing out places where we provide safer replacements. As for std::copy specifically, that is not deprecated. Most uses of std::copy pass unchanged without warning. Only some uses of unchecked iterators are flagged with warnings to let people know there are safer alternatives. Using unchecked iterators causes warnings because they're dangerous and a source of bugs, including security exploits. For example, it's really easy to accidentally make an iterator "range" that isn't a range in ways ranging from fairly obvious (e.g., a range where first and last don't point into the same container, or first isn't before last) to fairly subtle (e.g., first and/or last are invalidated iterators), all of which are as bad as gets and strcpy because they are latent buffer overruns; any algorithm using such a non-range can charge off the (real) end into uncharted memory. For another example, even without an iterator range, just a single iterator that has been invalidated is often just as unsafe to use as a dangling pointer. That's why Andrei and I made "Use a checked STL implementation" the first item in the STL Algorithms section of "C++ Coding Standards" (www.gotw.ca/publications/c++cs.htm), and I didn't even realize that my product was going to actually flag use of unchecked iterators when I wrote that item. This issue of unchecked iterators can show up when using std::copy, so using std::copy *with unchecked iterators* generates a warning by default to let people know that they have a safer alternative they could be using (i.e., checked iterators). Generally the C++ standard library has fewer safety issues than the C standard library, because of its better abstractions, but there are a few places where there are land mines. The point of this warning exercise wasn't to identify all possible land mines, but to identify and provide safer alternatives for the land mines that can directly cause security holes in a customer's code and then emit a warning about those ones so that people know the alternatives exist. The latest builds have improved this area, and include links to the documentation describing what's going on and refine the wording to make it clearer. I hope that will help, and I'm sorry if this caused some confusion, but we are definitely not removing any standard features and never intended to imply that. We're just working (hard) to help our customers write code that doesn't contain buffer overruns and other security problems, and at that we emit only warnings so that people can ignore them if they choose not to care about those issues. We felt security was important enough to put the warnings on by default, while still fully supporting all of those standard functions. Thanks, Herb