Boost logo

Boost :

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:
> -------------------------
> *
> * 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:
> -----------------------
> *
> * 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æ

Boost list run by bdawes at, gregod at, cpdaniel at, john at