Subject: Re: [boost] [RFC] Boost library name mangling and Microsoft's 'secureSTL' feature.
From: John Maddock (john_at_[hidden])
Date: 2008-09-04 04:41:49
Jurko Gospodnetiæ wrote:
>> 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
>> 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.
I would prefer to have the compiler default the Boost default as well, and
yes I'm aware of the performance implications.
>> * Making a complete Boost library build using the MSVC toolset
>> 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
>> Build to do nothing. This would on the other hand mess up library
>> name mangling unless Boost Build were taught to know exactly what
>> each compiler or compiler version uses.
>> Please give your comments on at least the following:
>> * Feature name.
OK, but can we generalise to things like STLPort and libstdc++ debug
features as well?
>> * Any additional values that might be needed.
>> * Any additional compiler flags/options/preprocessor constants
>> might be related to this.
>> * Default value.
Same as the compiler/library default.
BTW, any changes made here will have to be synchronised to a revised
auto_link.hpp as well: just a heads up on that one.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk