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
"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 libstlportstlg.so 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
* more often.
#define _STLP_DEBUG_LEVEL _STLP_STLPORT_DBG_LEVEL
#define _STLP_DEBUG_LEVEL _STLP_STANDARD_DBG_LEVEL
/* 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
#define _STLP_DEBUG_UNINITIALIZED 1
#define _STLP_DEBUG_ALLOC 1
* Uncomment and provide a definition for the byte with which raw memory
* will be filled if _STLP_DEBUG_ALLOC or _STLP_DEBUG_UNINITIALIZED is
* 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: www.antiviruslab.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk