Hi all.
There have been requests to make Boost Build cleanly support Microsoft's 'secure STL'/'checked iterators' feature.
After collecting some feedback both here and on IRC below are the summarized design suggestions. Please do keep the feedback coming in and see feedback requests at the end of this mail. 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?
------------------------- Checked iterator support: ------------------------- * http://msdn.microsoft.com/en-us/library/aa985965.aspx * Use _SECURE_SCL to enable. * Applicable with both debug and release run-time library variants. * Ensures that you do not overwrite the bounds of your container. * _SCL_SECURE_NO_WARNINGS may be used to disable warnings that get displayed due to using an unchecked iterator with a checked or standard algorithm versions.
----------------------- Debug iterator support: ----------------------- * http://msdn.microsoft.com/en-us/library/aa985982.aspx * Use _HAS_ITERATOR_DEBUGGING to enable. * Must use debug run-time library. * Detects invalidated iterator usage. * Detects using incompatible iterators in algorithms, e.g. those not belonging to the same container when expected to.
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. -------- 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). ------------------------- Design D (by Rene Rivera) -------------------------
Name the new feature "runtime-iterator-debugging", with values "off" and "checked". Set it to default to "off" for variant=release or variant=profile, and "checked" for variant=debug. This does change the current behavior, but in a less jarring way. It also is a generic but clear name which covers other STD implementations that have such iterators. It also allows for adding other kinds of iterator debugging if other STDs implement then now or in the future.
This does not allow freely combing checked-iterator and debugging-iterator concepts. On the other hand it does not seem like such a loss to add a feature value 'full' which would enable both checked & debugging iterators and not allow enabling debugging iterators without checked ones. We need more information on how other compilers & libraries implement this to decide whether this is 'good enough'. Name mangling: <checked-iterators>checked adds 'c' to library name if enabled (assuming it's applicable). Name mangling: <debugging-iterators>full adds 'f' to library name if enabled (assuming it's applicable). ------------------------- Design C (by Rene Rivera) -------------------------
Use the existing "runtime-debugging" feature to set the SCL_SECURE define. This has the advantage that the default behavior is the current behavior and there's no new feature name to fret about.
This is a simple solution requiring no library name changes and no new features. On the other hand this limits the user to not being able to select checked iterator debugging in release builds and does not allow the user to select debugging iterators independently of checked ones. Again, as before, we need more feedback about how other compilers & libraries implement these features in order to decide whether this solution is 'good enough'. ---------------------------------------------------- Design A (discarded design, overruled by 'Design B') ---------------------------------------------------- This is the same design as described in the original mail posting. Turns out to be pretty much incomplete as it misses the 'debugging iterators' concept completely. Feature: <msvc-checked-iterators> 'on' --> _SECURE_SCL=1 'off' (default) --> _SECURE_SCL=0 Name mangling: <msvc-checked-iterators> adds 'c' to library name if enabled (assuming it's applicable). Additional comments. * 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 or by smuggling them in under the guise of some other feature, e.g. <runtime-debugging>. * We can choose clean default value consistent between different toolsets or we can make each toolset define its own 'default'. Having each toolset define its own default though might be problematic to implement. Currently I prefer one clear default for all. However which gets chosen does not seem all that important. * 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. * Intel toolset already unconditionally disables the _SECURE_SCL setting. Please give your comments on at least the following: * Feature names. * Any additional values that might be needed. * Any additional compiler flags/options/preprocessor constants that might be related to this. * Default values. * Library name mangling. * Any additional compilers & libraries this might affect., e.g. Comeau, Intel, gcc, stlport, etc. Could someone please provide more detailed information on how they support these or similar features. Thanks again for all the help on this. Best regards, Jurko Gospodnetić