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