Re: [boost] Bug/Incompatibility: Visual C++ 2005 checkediteratorslead to major crashes

Dave Abrahams wrote:
What interface would you consider appropriate? Right now
bjam ... define=_SECURE_SCL=0 ...
works with BBv2. Do you want some kind of more descriptive syntax?
bjam checked_iterators=no
?? That wouldn't be appropriate if _SECURE_SCL=0 has effects other than turning off iterator checking.
IIRC, using _SECURE_SCL means that VC8 will replace some calls to strcpy, et. al. with the MS str***_s equivalents. There may be other changes as well. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Reece Dunn wrote:
Dave Abrahams wrote:
What interface would you consider appropriate? Right now
bjam ... define=_SECURE_SCL=0 ...
works with BBv2. Do you want some kind of more descriptive syntax?
bjam checked_iterators=no
?? That wouldn't be appropriate if _SECURE_SCL=0 has effects other than turning off iterator checking.
IIRC, using _SECURE_SCL means that VC8 will replace some calls to strcpy, et. al. with the MS str***_s equivalents. There may be other changes as well.
I think you're confusing with other defines such as _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES. From MSDN: "_SECURE_SCL If defined as 1, unsafe iterator use causes a runtime error. If defined as 0, checked iterators are disabled. The exact behavior of the runtime error depends on the value of _SECURE_SCL_THROWS. The default value for _SECURE_SCL is 1, meaning checked iterators are enabled by default." more info: http://msdn2.microsoft.com/en-US/library/y9ww7c1a.aspx (all about checked iterators) http://msdn2.microsoft.com/en-us/library/8ef0s5kh.aspx (security enhancements in the CRT) Tanguy

What interface would you consider appropriate? Right now bjam ... define=_SECURE_SCL=0 ... works with BBv2. Do you want some kind of more descriptive syntax?
this is *almost* fine. The problem is that when library is linked with program that does have this macro defined as _SECURE_SCL=1 ...
From MSDN: "_SECURE_SCL If defined as 1, unsafe iterator use causes a runtime error. If defined as 0, checked iterators are disabled. The exact behavior of the runtime error depends on the value of _SECURE_SCL_THROWS. The default value for _SECURE_SCL is 1, meaning checked iterators are enabled by default."
... there will be multiple *different* definitions of iterators, which clearly is ODR violation. This will cause all kind of nasty problems. But we already have (very) simple tool to protect against ODR violations - different names for libraries built with different options. Thus I suggest to extend msvc-8.0 toolset with definition of this feature AND library filename tag (we could have "i - checked iterators" similar to "s - static link to runtime; g - debug runtime" etc.) AND augment autolinking feature to take _SECURE_SCL into account when defining library name to link with. I also want to point out that msvc-8.0 is not the only toolset that would benefit from it, as IIRC there are at least two implementations of standard C++ library that provide some flavour (in very general meaning) of "checked" iterators - Dinkumware and STLPort. It means that "checked_iterators" feature does not have to be specific to msvc-8.0 B.

Bronek Kozicki <brok@rubikon.pl> writes:
... there will be multiple *different* definitions of iterators, which clearly is ODR violation. This will cause all kind of nasty problems. But we already have (very) simple tool to protect against ODR violations - different names for libraries built with different options.
You're right. It's an ABI change and thus ideally it should be a non-free feature (unlike <define>) in the build system so binaries so built are distinguished from one another. But the question remains whether we should be providing the libraries built both ways as part of the default installation. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (4)
-
Bronek Kozicki
-
David Abrahams
-
Reece Dunn
-
Tanguy Fautre