Re: [boost] [iostreams][vc8]deprecetedstandardlibrarymemberfunctions; fatal linker error [OT]

From: Herb Sutter (hsutter_at_[hidden])
Date: 2005-07-05 10:19:50

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