Question

What is the relation between _SECURE_SCL and _HAS_ITERATOR_DEBUGGING.
Is it possible to turn on/off range checking and preserve binary compatibility?

Any difference between 2008 and 2010 versions?

Answer 1

Stephan Lavavej has provided some detail on this _SECURE_SCL and _HAS_ITERATOR_DEBUGGING:

From http://blogs.msdn.com/b/vcblog/archive/2007/08/10/the-future-of-the-c-language.aspx

Iterator debugging, enabled by
_HAS_ITERATOR_DEBUGGING, performs powerful correctness verification.
Iterator checking, enabled by
_SECURE_SCL, performs minimal checks that serve as a last line of security
defense. For example, _SECURE_SCL
will terminate a program that triggers
a heap overrun with a vector iterator.

All that is explained by MSDN
documentation. The story behind this
is interesting. The
_HAS_ITERATOR_DEBUGGING functionality was provided by Dinkumware, the
company that licenses their most
triumphant implementation of the
Standard Library for inclusion in
Visual Studio. The _SECURE_SCL
functionality was added by Microsoft,
in order to improve the security of
programs running on Windows. In order
to perform their checks, both
_HAS_ITERATOR_DEBUGGING and _SECURE_SCL make iterators contain additional data members, such as
pointers to their parent containers.
_HAS_ITERATOR_DEBUGGING, because it is enabled by default in debug mode (and
not obtainable in release mode), also
builds singly linked lists that allow
containers to refer to all of their
iterators. This is expensive
performance-wise, but performance is
not critical in debug mode, and this
enables excellent checks.

_SECURE_SCL, because it is enabled by default in release mode, strives to
impose minimal performance penalties.
Therefore, when it is enabled,
although iterators have pointers back
to their containers, containers don’t
have pointers to their iterators.
(Updating “iterator lists” is too
time-consuming for release mode.)

Note that starting in VS 2010, _SECURE_SCL is no longer enabled by default in release mode (the above excerpt is from 2007).

As described in this bug report (http://connect.microsoft.com/VisualStudio/feedback/details/334315/has-iterator-debugging-0-causes-crash), both _SECURE_SCL and _HAS_ITERATOR_DEBUGGING affect the ABI:

_SECURE_SCL and _HAS_ITERATOR_DEBUGGING significantly change the behavior and
representations of STL containers and
iterators. VC9 (Visual Studio 2008)
made the representations of STL
containers and iterators even more
strongly dependent on _SECURE_SCL and
_HAS_ITERATOR_DEBUGGING (this was done to fix a conformance bug).

Because these macros change the
representations of STL objects, you
must observe certain rules when
changing these macros from their
defaults. I described the rules here:
http://blogs.msdn.com/vcblog/archive/2007/08/10/the-future-of-the-c-language.aspx#4617984 To summarize, the macros must be
consistent within each binary (EXE or
DLL), and furthermore, binaries that
pass STL objects to each other must
have consistent macro settings. Your
example involves an EXE and DLL
passing a vector between
themselves, so the EXE and DLL need to
have the same _SECURE_SCL and
_HAS_ITERATOR_DEBUGGING settings.

These rules apply to VC8, VC9, and all
future versions. Your code happened to
work with VC8 (Visual Studio 2005),
but would fail if it did more
complicated things.