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

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-07-02 14:17:32

Jeff Garland wrote:
> On Sat, 2 Jul 2005 10:41:00 -0600, Jonathan Turkanis wrote
>
>>> Interestingly these API's aren't documented as deprecated in the SDK
>>> as far as I can see, so I wonder if someone just made a mistake?
>>
>> I think it has to be a mistake to deprecate essential member
>> functions without introducing replacements.
>
> I haven't been following this thread closely, but are you saying
> there aren't some sort of safe replacements?

Apparently so. For many of the deprecated functions there's a recommended safe
version with the _s suffix, and most of these are proposed for standardization
(see, e.g., http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1055.pdf.)

But in the cases I'm talking about, there seem to be no new 'safe' versions. In
fact, it's hard see how there could be, since the existing functions already
provide a buffer size parameter. For example, what would basic_istream::read_s
look like?

>>> 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.
>
> I really don't think we should disparage them for this effort. This
> is a beta , after all, and it's sort of the point of beta stuff to
> shake out these sort of issues. I've seen the cost of using some of
> these unsafe functions in big software systems.  You can create
> incredibly subtle, and hard to find intermitant bugs by doing strcpy
> into stack-based buffers.

I'm not against the _s functions, by any means, and I'm willing to cut microsoft
some slack in a beta product. But it looks like whoever sprinkled the
__declspec's all over the place didn't have a clear idea what he was doing.

> So the fact that Microsoft is trying to raise awareness and move
> things forward -- I find it hard to argue against this.  This
> particular approach might appear 'heavy handed', but it has us
> talking ;-)

About the wrong issues, though ;-)

Jonathan