Boost logo

Boost :

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

[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>

[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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at