Re: [boost] [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

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
news:<g9neff$v6f$1_at_[hidden]>...

>   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
based 
> on my own personal choices and current understanding of all the
feedback 
> 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
for 
> 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,
at 
> 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...

Yes

>    * 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.

Greetings,
Johannes

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
invalidates iterators
 *                       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
abort.
 * If you prefer an exception define the following macro. The thrown
exception
 * will be the Standard runtime_error exception.
 */
#define _STLP_DEBUG_MODE_THROWS

/*
 * 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
automatically.
 */

#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
defined.
 * Choose a value which is likely to cause a noticeable problem if
dereferenced
 * or otherwise abused. A good value may already be defined for your
platform.
 */

#define _STLP_SHRED_BYTE 0xA3

____________
Virus checked by G DATA AntiVirusKit
Version: AVK 19.305 from 04.09.2008
Virus news: www.antiviruslab.com