Visual Studio debug iterators

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.