Secure template overloads with VC++ 2005/8

[John Pavel <jrp@…>]

VC++ 2008 provides

Many CRT functions have been deprecated in favor of newer, security-enhanced versions (for example, strcpy_s is the more secure replacement for strcpy). The CRT provides template overloads to help ease the transition to the more secure variants.

Defining _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES to be 1 enables template overloads of standard CRT functions that call the more secure variants automatically. If _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES is 1, then no changes to the code are necessary. A call to strcpy will be changed to a call to strcpy_s with the size argument supplied automatically.

Would it be possible to set in the default VC++ 2005/8 config

#define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1

See ​http://msdn2.microsoft.com/en-us/library/ms175759(VS.90).aspx for more details.

In addition functions that take a count, such as strncpy, can be picked up. To enable template overloads for the count functions, define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_COUNT to be 1. Before doing so, however, make sure that your code passes the count of characters, not the size of the buffer (a common mistake). Also, code that explicitly writes a null terminator at the end of the buffer after the function call is unnecessary if the secure variant is called. If you need truncation behavior, see _TRUNCATE.

[Peter Myerscough-Jackopson]

This is not default C/C++ behaviour, and although this option is available in MSVC++ should it not be turned on explicitly by the user of BOOST. If the change is so transparent I should be able to turn it on or off, but if BOOST automatically turns it on and I want it off this will cause unending problems. Similarly for portability reasons I will get different behaviour when moving from an MSVC++ platform to a non-MSVC++ platform, and the reason will be hidden from me.

[John Maddock]

John: I'm also really not sure about this, it very much feels like the wrong thing to do to change this setting in a *header*. If you really think we should go down this route, please reopen *and* raise the issue for discussion on the list.

Regards, John Maddock.