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ć