Re: [reSIProcate] Visual Studio 2005 compilation warnings of 1.4 branch
Matthias Moetje wrote:
The safe string functions are in fact not underscore-prefixed; at
least those not starting with 'str'. Instead they are suffixed
with '_s' which isn't really that bad. Apart from prefixes and suffixes
in the end there is no doubt that these functions really improve code
quality and security.
I hope to be able to start with the function replacement in Jan
Or Feb 2009 if there are no objections.
Don't.
Here's what's going on with the *_s functions. Microsoft submitted a
batch of "more secure" functions (such as strcpy_s) to the ISO/IEC for
potential inclusion in a future version of the C standard (the draft
that defines these proposed functions is here:
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1135.pdf). As far as I
can tell, they have not been accepted for future inclusion yet, and
there is significant push-back in the developer community against this
set of functions
(<http://sources.redhat.com/ml/libc-alpha/2007-09/msg00069.html>,
<http://www.informit.com/blogs/blog.aspx?uk=Theyre-at-it-again>,
<http://fsfoundry.org/codefreak/2008/09/15/security-crt-safer-than-standard-library/>).
In any case, these functions do not appear to have been implemented
under OS X Leopard; nor is it in any of the libc versions that I can
find installed by default with Ubuntu or Fedora (both glibc; see the
first link in my list above). I suspect these functions have not been
widely implemented outside of Redmond.
For most of the string functions, you can accomplish the same security
properties with C89/C99 functions like strncpy, as long as you are
careful to null-terminate your destination buffer when you're done.
So, if you wanted to go through and fix things to use the C89 "safer"
functions (like strncpy), that would be a Good Thing -- but it's
apparently not going to fix the Microsoft compiler warnings. For that,
you'll apparently need to convince Microsoft to stop being so
provincial. Or you can define '"_CRT_SECURE_NO_WARNINGS" in the project,
which is probably the best approach under the circumstances.
/a
P.S. Digging through this mess, I was pointed to an interesting
development in the draft C++0x standard: "The class template auto_ptr is
deprecated. [ Note:The class template unique_ptr (20.6.5) provides a
better solution.
— end note ]"