[boost] Boost and (Microsoft's) _SECURE_SCL

Subject: [boost] Boost and (Microsoft's) _SECURE_SCL
From: Martin B. (0xCDCDCDCD_at_[hidden])
Date: 2010-11-03 07:38:02

Boost and Microsoft's _SECURE_SCL

Long story short of this post: Are there any plans (left) to add 
additional name mangling to the boost libs on Windows to address the 
problem of mismatched _SECURE_SCL setting?

The Microsoft (Dinkumware) _SECURE_SCL=1 macro [1],[2] adds additional 
checks to standard library iterators/containers, rendering them ABI 
incompatible with _SECURE_SCL setting 0 vs. 1.

This in turn leads to crashes when using a wrong combination of this 
flag. For example: [3]

This has been discussed numerous times before: [4], [5], [6] -- see [5] 
for a list of further links to more threads.

A trac issue [7] to add a specific build option has been closed as invalid.

What I have been unable to determine is what the status is on supporting 
an additional *name mangling scheme* for the _SECURE_SCL option. From 
what I can discern from the current Getting Started page [8], not only 
do we not support any such name mangling, but the _SECURE_SCL macro (or 
the new _ITERATOR_DEBUG_LEVEL macro in VS2010) is not even mentioned on 
the Getting Started page.

Since Visual Studio 2005 defaulted to _SECURE_SCL=1 and boost just uses 
the default, many people hit this when they used _SECURE_SCL=0 to 
improve performance in their release builds. (Which, as an aside, 
doesn't yield too much, as the real showstopper is the - independent! - 
_HAS_ITERATOR_DEBUGGING macro and that is only active in debug builds 
anyway.)

In Visual Studio 2010, the situation is reversed, as Microsoft decided 
to now default to _SECURE_SCL=0. That means the people who change it to 
1 in their release build for additional security will be bitten by the 
problem. (Or not, as it seems that they added some link-time checks in 
VS2010 to detect mismatches regarding the _ITERATOR_DEBUG_LEVEL. [9])

OK, so now again: Are there any plans (left) to add additional name 
mangling to the boost libs on Windows to address the problem of 
mismatched _SECURE_SCL setting? -- Or are we just going to ignore the 
issue since VS2010 defaults to the "boost preferred" - off - option now 
anyway? By "boost preferred" I mean that from some of the discussions it 
seemed to me that there was doubts w/rgd to complexity issues etc. when 
_SECURE_SCL is on.

cheers,
Martin

p.s.: FWIW, here's how /I/ compile my release version of boost 1.44
on VS2005:
bjam.exe --build-type=complete variant=release toolset=msvc-8.0
          threading=multi define=_SECURE_SCL=0 --with-regex
          --with-program_options --with-test --with-serialization
          stage

   [1] Visual Studio 2005 - _SECURE_SCL :
   http://msdn.microsoft.com/en-us/library/aa985896%28VS.80%29.aspx
   [2] Visual Studio 2010 - _SECURE SCL :
   http://msdn.microsoft.com/en-us/library/aa985896%28v=VS.100%29.aspx
   [3] access violation with _SECURE_SCL turned off :
   http://lists.boost.org/boost-users/2009/02/45137.php
   [4] _SECURE_SCL for msvc (2009) :
   http://thread.gmane.org/gmane.comp.lib.boost.devel/185898/focus=185987
   [5] MSVC _SECURE_SCL causes ABI change, ODR violation - mangle
            library names? :
   http://lists.boost.org/boost-users/2008/10/41253.php
   [6] Re: Bug/Incompatibility: Visual C++ 2005 checkediteratorslead to
       major crashes :
   http://thread.gmane.org/gmane.comp.lib.boost.devel/144082/focus=144089
   [7] Add build option to define _secure_scl=0 + add runtime check to
       ensure no ODR violation :
   https://svn.boost.org/trac/boost/ticket/2086
   [8] Boost 1.44 Getting Started on Windows :
   http://www.boost.org/doc/libs/1_44_0/more/getting_started/windows.html
   [9] Visual STuduio 2010 - detect_mismatch :
   http://msdn.microsoft.com/en-us/library/ee956429.aspx