Boost logo

Boost :

Subject: Re: [boost] [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.
From: Johannes Brunen (jbrunen_at_[hidden])
Date: 2008-09-04 04:54:25

Hello Jurko,

"Jurko Gospodnetic" <jurko.gospodnetic_at_[hidden]> schrieb im Newsbeitrag

> First some collected background information related to Microsoft's
> checked & debugging iterator support to get a clearer image of what we

> are modeling. And could someone please collect a similar summary for
> other compilers/libraries?

Below you can find a excerpt of the stlports user config file. I do not
use the stlport so maybe someone else can give more profound info.

> Now the design summaries in order of preference. Note that the list
> is a 'work in progress' and the ordering and the 'importance' are
> on my own personal choices and current understanding of all the
> received so far. Feel free to holler if you do not agree with them and

> I'll update as needed.

Currently, I favor design B.

> --------
> Design B
> --------
> Improved version of the originally suggested 'Design A' allowing
> debugging iterators and making the features msvc toolset specific,
> although the exact implementation described here is based on the msvc
> compiler documentation:
> Feature: <checked-iterators>
> 'on' --> _SECURE_SCL=1
> 'off' (default) --> _SECURE_SCL=0
> Name mangling: <checked-iterators> adds 'c' to library name if
> enabled (assuming it's applicable).
> Feature: <debugging-iterators>
> 'on' --> _HAS_ITERATOR_DEBUGGING defined
> 'off' (default) --> _HAS_ITERATOR_DEBUGGING not defined
> <runtime-debugging>off & <debugging-iterators>on are incompatible.
> Name mangling: <debugging-iterators> adds 'e' to library name if
> enabled (assuming it's applicable).

> * We really need to mangle library names to make it clear which
> libraries have checked/debugging iterators enabled and which do not,
> for those compiled with MSVC, as these options produce binary
> incompatible libraries. This can be done by either adding new tag
> letters for these features...


> * All this will affects only code compiled using MSVC compiler
> versions 8.0 & above. It may also affect other non-MSVC toolsets as we

> get more information on them.

Stlport gives also additional support for checking.


P.S.: Excerpt from the STLport user-config.h file responsible for
configuration of the library. I did take all entries which might be
relevant in the context.

 * Set _STLP_DEBUG to turn the "Debug Mode" on.
 * That gets you checked iterators/ranges in the manner
 * of "Safe STL". Very useful for debugging. Thread-safe.
 * Please do not forget to link proper STLport library flavor
 * (e.g or libstlportstlg.a) when you set this flag
 * in STLport iostreams mode, namespace customization guaranty that you
 * link to the right library.

#define _STLP_DEBUG 1

 * You can also choose the debug level:
 * STLport debug level: Default value
 * Check only what the STLport implementation
consider as invalid.
 * It also change the iterator invalidation schema.
 * Standard debug level: Check for all operations the standard consider
as "undefined behavior"
 * even if STlport implement it correctly. It also
invalidates iterators
 * more often.


/* When an inconsistency is detected by the 'safe STL' the program will
 * If you prefer an exception define the following macro. The thrown
 * will be the Standard runtime_error exception.

 * Use this option to catch uninitialized members in your classes.
 * When it is set, construct() and destroy() fill the class storage
 * with _STLP_SHRED_BYTE (see below).
 * Note : _STLP_DEBUG and _STLP_DEBUG_ALLOC don't set this option


 * Uncomment and provide a definition for the byte with which raw memory
 * Choose a value which is likely to cause a noticeable problem if
 * or otherwise abused. A good value may already be defined for your

#define _STLP_SHRED_BYTE 0xA3

Virus checked by G DATA AntiVirusKit
Version: AVK 19.305 from 04.09.2008
Virus news:

Boost list run by bdawes at, gregod at, cpdaniel at, john at