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

Subject: [boost] [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.
From: Jurko Gospodnetiæ (jurko.gospodnetic_at_[hidden])
Date: 2008-09-03 16:57:20

   Hi all.

   There have been requests to make Boost Build cleanly support 
Microsoft's 'secure STL'/'checked iterators' feature.

   Here's is one suggested implementation and how that will affect 
building Boost libraries on Windows:

   We add a new <msvc-checked-iterators> Boost Build feature with values 
'off' and 'on' and 'off' being the default.

   The effect of the feature would be to define the SCL_SECURE
preprocessor constant to 1 for feature value 'on' or to 0 for feature 
value off. This would affect only code compiled using MSVC compiler 
versions 8.0 & above.

   Libraries compiled with compilers affected by this setting would have 
their name mangling changed as follows:

     * If the setting is 'off' there would be no change.

     * If the setting is 'on' the name would get en extra letter 'c' 
added to its 'runtime tag' letter group (together with 's' for 
statically linked libraries, 'd' for debug, 'p' for the stlport standard 
library, etc.).

   Effects this would have on Boost libraries:

     * If we implement the proposed solution the default Boost library 
build behaviour will change. Boost libraries built by default will have 
Microsoft's secure STL (a.k.a. checking iterator) support disabled while 
  currently, when we do nothing explicit about those settings, Microsoft 
compilers enable that support by default.

     * Making a complete Boost library build using the MSVC toolset will 
take twice as long as there may now be twice as many property 
combinations affecting the build. On the other hand user can always 
easily choose from the build command line which versions he wants in 
case he wants a subset. Selecting msvc-checked-iterators=on would get 
the current default behaviour.

   Some extra ideas to consider:

     * Add an additional 'default' feature value which would cause Boost 
Build to do nothing. This would on the other hand mess up library name 
mangling unless Boost Build were taught to know exactly what defaults 
each compiler or compiler version uses.

   Please give your comments on at least the following:

     * Feature name.

     * Any additional values that might be needed.

     * Any additional compiler flags/options/preprocessor constants that 
might be related to this.

     * Default value.

     * Library name mangling.

     * Any additional compilers this might affect, e.g. Comeau, Intel, etc.

     * Any additional runtime libraries this might affect, e.g. stlport.

   Many thanks for any feedback you can provide.

   Best regards,
     Jurko Gospodnetiæ