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: Jurko Gospodnetiæ (jurko.gospodnetic_at_[hidden])
Date: 2008-09-03 21:43:13

   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æ