views:

291

answers:

5

I just recently changed my IDE to MS Visual Studio 2005 coming from MSVC++ 6, and I've gotten a lot of deprecation warnings. Rather than ignore the warning, I started to change them to the _s equivalents. However, I then found out that these were microsoft-only implementations.

I read somewhere that they were pushing for these to become part of the standard. Is it?

Is it a good idea to use these _s functions? Or should I use something else?

Thanks.

+1  A: 

You upgraded your IDE and also upgraded your Microsoft libraries. Frankly you can continue to use your old libraries as they continue to be kept (for backwards compatibility) although Microsoft has said that they are going to actually start taking out some of these older functions. I would say that if you're developing forward then you can use the newer functions; if you're developing backwards (or not worrying what the version is) then you might want to use the older functions.

Suroot
Thanks, maybe I'll just use the _CRT_SECURE_NO_WARNINGS macro..
krebstar
A: 

If you're targeting the Microsoft platform, by all means use them. Even if you're not, you can always implement them yourself when (or if) you need to port your software to a non-Microsoft platform.

Worst case is that you end up using a few #ifdefs to conditionally compile.

paxdiablo
+7  A: 

The *_s() functions are not part of the C standard, but there is a pending 'Technical Report' proposing that they be added (I'm not sure if the routines in the TR are exactly the same as Microsoft's or if they're just similar).

TR 24731-1: Extensions to the C Library Part I: Bounds-checking interfaces:

If you want to continue to use the old functions you can keep the deprecation warnings quiet by defining the macro _CRT_SECURE_NO_WARNINGS (was _CRT_SECURE_NO_DEPRECATE which might still be supported).

Michael Burr
Just to support, _CRT_SECURE_NO_DEPRECATE works on some like strncpy, etc, while for others like fopen() you need to #pragma warning(disable:4996). Supposedly you could just define _CRT_SECURE_NO_WARNINGS but it didn't work for me..
krebstar
Those `_s` functions are now part of C1X Annex K.
KennyTM
+1  A: 

They're being considered for standardization, as far as I'm able to tell. The proposal is TR 24731.

As for whether it's a good idea to use them, I'd say yes. I don't much like the way they catch errors but I believe you can provide them with your own handler. If you need cross-platform compatibility you have two choices: implement them with macros on the non-Windows platforms or turn off the deprecation warnings.

After doing a review through a large codebase I determined that it's nearly impossible to get all programmers to use the C standard library functions for string manipulation correctly, so everything that aims to correct that is a welcome addition.

Dan Olson
The problem is that MS made the step of unilaterally introducing the functions as if they were a standard and "deprecating" the "C" functions that were in the standard at the same time. It seems to me yet another way to force you to stay with their tools.
Jon Trauntvein
That's overly skeptical. They made a small internal improvement on the C standard library functions and rolled it into their public releases as well as submitting it for standardization. If it was a deliberate ploy to increase their market share, why try to standardize it?
Dan Olson
A: 

You should use the standard functions and disable whatever sadistic warnings Microsoft has turned on by default to discourage you from writing standards-conformant code. I seriously doubt the "_s functions" will ever be added to standard C (though they have been proposed) since they are an invention of a single vendor and have never been implemented by any other vendor. (Hey let's incorporate all of POSIX into the C standard while we're at it...)

R..