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

From: Bronek Kozicki (brok_at_[hidden])
Date: 2006-06-18 06:32:26

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