[boost] use of strcpy, strcat, etc in Boost libraries

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