From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-09-30 15:43:57
Hi All,
In my post on the "vc8.0 toolset (bjam)" thread, I commented that VC8
also warns when using the str[n]xxx APIs, because MS declares them
deprecated. There are several issues here:
[1] How does this impact Boost code that uses the <cstring> API?
Especially since they deprecate the strn variations as well, which are
safer, and considering that the "safe" versions are not yet a part of
the standard.
Would it be possible to put this in the Boost <cstring> header? I.e.
using the safe versions for VC8 and using the C9x API for the other
compilers/libraries.
[2] Does this affect the Intel compiler using the Dinkumware libraries
because Intel does not like how the library declares items deprecated.
(This is already an issue using the <locale> header and <hash_xxx>
extensions).
[3] What are the wider security issues of using strcpy, etc in Boost
code? The libraries should use the strnxxx variants for better
protection against buffer overrun attacks, but I found several instances
where strcpy was used (I haven't checked for strcat, strcmp and others)
instead of strncpy:
boost/regex/v4/regex_cstring.hpp (104): use of strcpy [via re_strcpy]
libs/regex -- various files using strcpy
libs/serialization/test/test_tools.hpp (69): use of strcpy [via STRCPY]
libs/smart_ptr/test/smart_ptr_test.cpp (139/223): use of strcpy
tools/build/jam_src -- execnt.c; regexp.c; variable.c
[4] Doing this, I found that regex was using re_strcpy as a workaround
for Borland using strxxx as macros when using intrinsics. Serialization
uses STRCPY for a similar workaround, and my fixed_string library uses
the following:
# if defined(__BORLANDC__) && defined(strcpy) // replace Borland
instrinsic string function
# undef strcpy
inline char * strcpy( char * dest, const char * src )
{
return( __strcpy__( dest, src ));
}
# endif
So: should the workarounds be placed in <cstring> and affected libraries
use the Boost version.
NOTE: I suggested telling Boost.Build to disable the deprecated API
warning for the upcoming release and then address these issues for the
next (1.33) release.
Thoughts? Comments?
Regards,
Reece