headers
Jurko Gospodnetić | 3 Sep 22:56

[RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

   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
(Continue reading)

Permalink | Reply |
headers
Michael Marcin | 3 Sep 23:35

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

Jurko Gospodnetić wrote:
> 
>   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.
> 

It sounds OK to me except 2 issues.

Are there other toolsets with checked iterator options?  I thought gcc 
and stlport had them. Perhaps the feature should be <checked-iterators>.

The default value should obey The Principle of Least Astonishment. IMO 
this means it should be equivalent to the toolset defaults.

Thanks,

Michael Marcin

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Mat Marcus | 3 Sep 23:50

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

2008/9/3 Michael Marcin <mike.marcin <at> gmail.com>:
> Jurko Gospodnetić wrote:
>>
>>  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.
>>
>
> It sounds OK to me except 2 issues.
>
> Are there other toolsets with checked iterator options?  I thought gcc and
> stlport had them. Perhaps the feature should be <checked-iterators>.

Microsoft offers two different features: checked iterators and
debugging iterators. Trying to map both to a single feature probably
wouldn't make sense here.

>
> The default value should obey The Principle of Least Astonishment. IMO this
> means it should be equivalent to the toolset defaults.

In this case, I believe that the principle of Don't Slow Down Inner
Loops By An Order of Magnitude should prevail. See

http://easyurl.net/high_cost
(Continue reading)

Permalink | Reply |
headers
David Abrahams | 4 Sep 01:14
Favicon
Gravatar

Re: [boost] [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.


on Wed Sep 03 2008, Michael Marcin <mike.marcin-AT-gmail.com> wrote:

> Jurko Gospodnetić wrote:
>>
>>   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.
>>
>
> It sounds OK to me except 2 issues.
>
> Are there other toolsets with checked iterator options?  I thought gcc and
> stlport had them. Perhaps the feature should be <checked-iterators>.

I was thinking the same.  GCC has them, MSVC has them, STLPort has them,
probably others have them.

> The default value should obey The Principle of Least Astonishment. IMO this
> means it should be equivalent to the toolset defaults.

I guess it depends on whether you think it's more astonishing to have
any chance of high performance absolutely slaughtered even in MSVC
release builds, and to have different defaults for the checked-iterator
setting on different platforms, or more astonishing for the default to
(Continue reading)

Permalink | Reply |
headers
Rene Rivera | 3 Sep 23:55

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

Jurko Gospodnetić wrote:
>   There have been requests to make Boost Build cleanly support 
> Microsoft's 'secure STL'/'checked iterators' feature.

Two alternatives...

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.

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.

--

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
dherring | 4 Sep 00:15

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

On Wed, 3 Sep 2008, Jurko Gospodneti? wrote:
>     * 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.).

Does the MSVC library ABI change depending on whether "secure STL" has 
been enabled?  If not, I'd suggest adding a build option but not adding 
yet another runtime tag.

Linking to boost libraries has already become tag soup -- try writing a 
portable configure script to figure out which name mangling was installed 
on a user's machine...  Its been done, but it runs 2^n slower than simply 
checking whether '$CXX -l<name>...' succeeds.

Later,
Daniel
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
David Abrahams | 4 Sep 01:15
Favicon
Gravatar

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.


on Wed Sep 03 2008, dherring-AT-ll.mit.edu wrote:

> On Wed, 3 Sep 2008, Jurko Gospodneti? wrote:
>>     * 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.).
>
> Does the MSVC library ABI change depending on whether "secure STL" has been
> enabled?  

Yes

--

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Marcus Lindblom | 4 Sep 10:36

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

dherring <at> ll.mit.edu wrote:
> On Wed, 3 Sep 2008, Jurko Gospodneti? wrote:
>>     * 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.).
> 
> Does the MSVC library ABI change depending on whether "secure STL" has 
> been enabled?  If not, I'd suggest adding a build option but not adding 
> yet another runtime tag.

It does, so it is impossible to link incompatible binaries. :(

We had to adjust site-config.jam and recompile boost to get it to work, 
since we disable these iterators by default. (Their performance hit is 
too severe.)

Cheers,
/Marcus
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Jurko Gospodnetić | 4 Sep 03:43

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

   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.
(Continue reading)

Permalink | Reply |
headers
Sebastian Redl | 4 Sep 11:00
Favicon

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

Jurko Gospodnetić wrote:
>   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?
Just a quick note: GCC's scheme works thus:

1) If _GLIBCXX_DEBUG is defined, the debug containers are made available.
2) These containers lie in the std::__debug namespace. To actually use 
them, the programmer needs to somehow use them explicitly. This can be 
done through using statements or declarations, through typedefs, or 
namespace aliases. There is no macro or compiler switch that replaces 
the normal containers automatically.

It is therefore an explicit choice by the programmer to use those 
containers, for every individual usage. No switching in the build system 
is necessary or even possible.

Sebastian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Giovanni Piero Deretta | 4 Sep 15:08

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

2008/9/4 Sebastian Redl <sebastian.redl <at> getdesigned.at>:
> Jurko Gospodnetić wrote:
>>
>>  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?
>
> Just a quick note: GCC's scheme works thus:
>
> 1) If _GLIBCXX_DEBUG is defined, the debug containers are made available.
> 2) These containers lie in the std::__debug namespace. To actually use them,
> the programmer needs to somehow use them explicitly. This can be done
> through using statements or declarations, through typedefs, or namespace
> aliases. There is no macro or compiler switch that replaces the normal
> containers automatically.
>
> It is therefore an explicit choice by the programmer to use those
> containers, for every individual usage. No switching in the build system is
> necessary or even possible.

Eh? I'm fairly sure that if the macro is defined, standard containers
are replaced by their debug counterpart. This is all you need to do to
enable debugging (I have caught many bugs in my code just by defining
that macro).

In fact IIRC debugging containers are always available even if you do
not define the macro and you can access them by explicitly using the
__debug namespace (but I've never done that).
(Continue reading)

Permalink | Reply |
headers
David Abrahams | 4 Sep 16:05
Favicon
Gravatar

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.


on Thu Sep 04 2008, "Giovanni Piero Deretta" <gpderetta-AT-gmail.com> wrote:

> 2008/9/4 Sebastian Redl <sebastian.redl <at> getdesigned.at>:
>> Jurko Gospodnetić wrote:
>>>
>>>  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?
>>
>> Just a quick note: GCC's scheme works thus:
>>
>> 1) If _GLIBCXX_DEBUG is defined, the debug containers are made available.
>> 2) These containers lie in the std::__debug namespace. To actually use them,
>> the programmer needs to somehow use them explicitly. This can be done
>> through using statements or declarations, through typedefs, or namespace
>> aliases. There is no macro or compiler switch that replaces the normal
>> containers automatically.
>>
>> It is therefore an explicit choice by the programmer to use those
>> containers, for every individual usage. No switching in the build system is
>> necessary or even possible.
>
> Eh? I'm fairly sure that if the macro is defined, standard containers
> are replaced by their debug counterpart. This is all you need to do to
> enable debugging (I have caught many bugs in my code just by defining
> that macro).

That's my experience too.
(Continue reading)

Permalink | Reply |
headers
Sebastian Redl | 4 Sep 16:13
Favicon

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

David Abrahams wrote:
> on Thu Sep 04 2008, "Giovanni Piero Deretta" <gpderetta-AT-gmail.com> wrote:
>
>   
>> 2008/9/4 Sebastian Redl <sebastian.redl <at> getdesigned.at>:
>>     
>>> Jurko Gospodnetić wrote:
>>>       
>>>>  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?
>>>>         
>>> Just a quick note: GCC's scheme works thus:
>>>
>>> 1) If _GLIBCXX_DEBUG is defined, the debug containers are made available.
>>> 2) These containers lie in the std::__debug namespace. To actually use them,
>>> the programmer needs to somehow use them explicitly. This can be done
>>> through using statements or declarations, through typedefs, or namespace
>>> aliases. There is no macro or compiler switch that replaces the normal
>>> containers automatically.
>>>
>>> It is therefore an explicit choice by the programmer to use those
>>> containers, for every individual usage. No switching in the build system is
>>> necessary or even possible.
>>>       
>> Eh? I'm fairly sure that if the macro is defined, standard containers
>> are replaced by their debug counterpart. This is all you need to do to
>> enable debugging (I have caught many bugs in my code just by defining
>> that macro).
(Continue reading)

Permalink | Reply |
headers
dherring | 4 Sep 19:51

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

On Thu, 4 Sep 2008, Sebastian Redl wrote:
> David Abrahams wrote:
>> on Thu Sep 04 2008, "Giovanni Piero Deretta" <gpderetta-AT-gmail.com> wrote:
>>> 2008/9/4 Sebastian Redl <sebastian.redl <at> getdesigned.at>:
>>>> Jurko Gospodneti? wrote:
>>>>
>>>>>  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?
>>>>>
>>>> Just a quick note: GCC's scheme works thus:
>>>>
>>>> 1) If _GLIBCXX_DEBUG is defined, the debug containers are made available.
>>>> 2) These containers lie in the std::__debug namespace. To actually use them,
...
>>>> It is therefore an explicit choice by the programmer to use those
>>>> containers, for every individual usage. No switching in the build system is
>>>> necessary or even possible.
...
> You're right, sorry. There's a strong using statement importing the
> entire debug namespace in debug mode.

Would it be possible to do something like this in boost?

For header-only libraries, the right preprocessor macros would control 
which iterators to use -- nothing needs to change. (?)

For other libraries, bjam would compile the sources multiple times, using 
preprocessor macros to put checked iterators and other variants in
(Continue reading)

Permalink | Reply |
headers
Peter Dimov | 4 Sep 19:26

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

>   Feature: <checked-iterators>
>       'on'            --> _SECURE_SCL=1
>       'off' (default) --> _SECURE_SCL=0

I believe that the default should match the VC default, which is 1.

This has no performance implications. Whether _SECURE_SCL is 0 or 1 in a 
particular project is decided by the user, not us. The autolink code will 
check the macro value and attempt to link to the appropriate Boost library. 
What is _built_ by default should match what is _used_ by default; it 
doesn't matter which one is faster, the choice is not ours to make.

>   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

Not defined means "on" in debug builds, "off" in release builds. Defined to 
0 means off. Defined to 1 means "on" in debug builds, "off", warning and 
redefintion back to 0 in release builds.

If we build no debug libraries, this default doesn't matter for MSVC. If we 
do, the default should again match the compiler default, either 1 or not 
defined. 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
Mat Marcus | 4 Sep 19:45

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

On Thu, Sep 4, 2008 at 10:26 AM, Peter Dimov <pdimov <at> pdimov.com> wrote:
>>  Feature: <checked-iterators>
>>      'on'            --> _SECURE_SCL=1
>>      'off' (default) --> _SECURE_SCL=0
>
> I believe that the default should match the VC default, which is 1.
>
> This has no performance implications.
[snip]

I wouldn't say that it has *no* performance implications. Default
settings often have large impact since many people don't take the time
to learn the meaning of the various settings or tune them. In my
experience, this is especially true with a complex tool like boost
build. I expect this would result in a large number of executables
that are needlessly slow, as is the case today. Vendors are not
infallible--I believe that Microsoft made a mistake in defaulting the
flag to 'on' for release builds, and that most users just assume that
they are not paying a release price for this "security". We have an
opportunity to employ to follow conventional best-practices with boost
build defaults, and I still lean in favor of doing so.

Of course there are dangers. Mixing and matching a component built
with the IDE defaults with a component built with (different) boost
build defaults is a recipe for disaster. Then again, it is no great
thing to ship a product with slow generic inner loops. In the end, I
suppose that one could make the argument that one way or another users
must be educated. Nonetheless, I think we should preserve the spirit
of C++ by avoiding needless release performance tax on user-written
generic algorithms.
(Continue reading)

Permalink | Reply |
headers
David Abrahams | 4 Sep 19:57
Favicon
Gravatar

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.


on Thu Sep 04 2008, "Mat Marcus" <mat-lists-AT-emarcus.org> wrote:

> On Thu, Sep 4, 2008 at 10:26 AM, Peter Dimov <pdimov <at> pdimov.com> wrote:
>>>  Feature: <checked-iterators>
>>>      'on'            --> _SECURE_SCL=1
>>>      'off' (default) --> _SECURE_SCL=0
>>
>> I believe that the default should match the VC default, which is 1.
>>
>> This has no performance implications.
> [snip]
>
> I wouldn't say that it has *no* performance implications. Default
> settings often have large impact since many people don't take the time
> to learn the meaning of the various settings or tune them. In my
> experience, this is especially true with a complex tool like boost
> build. I expect this would result in a large number of executables
> that are needlessly slow, as is the case today. Vendors are not
> infallible--I believe that Microsoft made a mistake in defaulting the
> flag to 'on' for release builds, and that most users just assume that
> they are not paying a release price for this "security". We have an
> opportunity to employ to follow conventional best-practices with boost
> build defaults, and I still lean in favor of doing so.
>
> Of course there are dangers. Mixing and matching a component built
> with the IDE defaults with a component built with (different) boost
> build defaults is a recipe for disaster. 

Yes, but unless you go out of your way to disable auto-link, that can't
(Continue reading)

Permalink | Reply |
headers
Peter Dimov | 4 Sep 19:56

Re: [RFC] Boost library name mangling and Microsoft's'secure STL' feature.

Mat Marcus:

> I wouldn't say that it has *no* performance implications. Default
> settings often have large impact since many people don't take the time
> to learn the meaning of the various settings or tune them. In my
> experience, this is especially true with a complex tool like boost
> build.

Yes, you are right. The default does have performance implications for 
people who use Boost.Build for their projects. (Although I wouldn't expect 
that particular audience to not take the time to learn the settings.)

What I said applies to the "ordinary" user of Boost. He downloads Boost, 
builds or installs it, then makes use of it in his own project. In this 
case, the state of _SECURE_SCL is determined by the user. Whatever is built 
or installed by default should match what most of our "ordinary" users need, 
so that the autolink "just works". (Or we could just build both.) 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Michael Marcin | 4 Sep 21:25

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

Mat Marcus wrote:
> On Thu, Sep 4, 2008 at 10:26 AM, Peter Dimov <pdimov <at> pdimov.com> wrote:
>>>  Feature: <checked-iterators>
>>>      'on'            --> _SECURE_SCL=1
>>>      'off' (default) --> _SECURE_SCL=0
>> I believe that the default should match the VC default, which is 1.
>>
>> This has no performance implications.
> [snip]
> 
> I wouldn't say that it has *no* performance implications. Default
> settings often have large impact since many people don't take the time
> to learn the meaning of the various settings or tune them. In my
> experience, this is especially true with a complex tool like boost
> build. I expect this would result in a large number of executables
> that are needlessly slow, as is the case today. Vendors are not
> infallible--I believe that Microsoft made a mistake in defaulting the
> flag to 'on' for release builds, and that most users just assume that
> they are not paying a release price for this "security". We have an
> opportunity to employ to follow conventional best-practices with boost
> build defaults, and I still lean in favor of doing so.
> 
> Of course there are dangers. Mixing and matching a component built
> with the IDE defaults with a component built with (different) boost
> build defaults is a recipe for disaster. Then again, it is no great
> thing to ship a product with slow generic inner loops. In the end, I
> suppose that one could make the argument that one way or another users
> must be educated. Nonetheless, I think we should preserve the spirit
> of C++ by avoiding needless release performance tax on user-written
> generic algorithms.
(Continue reading)

Permalink | Reply |
headers
Jurko Gospodnetić | 4 Sep 20:28

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

   Hi Peter.

>>   Feature: <checked-iterators>
>>       'on'            --> _SECURE_SCL=1
>>       'off' (default) --> _SECURE_SCL=0
> 
> I believe that the default should match the VC default, which is 1.
> 
> This has no performance implications. Whether _SECURE_SCL is 0 or 1 in a 
> particular project is decided by the user, not us. The autolink code 
> will check the macro value and attempt to link to the appropriate Boost 
> library. What is _built_ by default should match what is _used_ by 
> default; it doesn't matter which one is faster, the choice is not ours 
> to make.

   I fail to see how the auto-link code takes things out of our hands.

   Of course, auto-link code will need to be aware of the default 
settings (i.e. those with not explicit macro being defined) for each 
supported compiler in order to work correctly in any build environment. 
However, do not quite understand how this affects what default feature 
value choice we make in Boost Build. Which ever choice we make (on, off 
or compiler default), we will need to encode the on/off decision in the 
library's name. We will also need to set the corresponding preprocessor 
constants during compilation.

>>   Name mangling: <checked-iterators> adds 'c' to library name if 
>> enabled (assuming it's applicable).
>>
>>   Feature: <debugging-iterators>
(Continue reading)

Permalink | Reply |
headers
Jurko Gospodnetić | 4 Sep 20:42

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

[Bah, the original message went out too soon... here's a finished one. I 
apologize or the noise.]

    Hi Peter.

>>   Feature: <checked-iterators>
>>       'on'            --> _SECURE_SCL=1
>>       'off' (default) --> _SECURE_SCL=0
>
> I believe that the default should match the VC default, which is 1.
>
> This has no performance implications. Whether _SECURE_SCL is 0 or 1 in 
> a particular project is decided by the user, not us. The autolink code 
> will check the macro value and attempt to link to the appropriate 
> Boost library. What is _built_ by default should match what is _used_ 
> by default; it doesn't matter which one is faster, the choice is not 
> ours to make.

   I fail to see how the auto-link code takes things out of our hands.

   Of course, auto-link code will need to be aware of the default
settings (i.e. those with no explicit macro being defined) for each
supported compiler in order to work correctly in any build environment.
However, I do not quite understand how this affects what default feature
value choice we can make in Boost Build.

   The auto-link code should then fine based on the preprocessor 
constants we set, no matter which choice we considered to be 'the 
default one' in Boost Build. Which ever choice we end up making (on, off 
or compiler default), we will need to encode the on/off decision in the
(Continue reading)

Permalink | Reply |
headers
John Maddock | 4 Sep 10:41

Re: [RFC] Boost library name mangling and Microsoft's 'secureSTL' feature.

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
>> 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.).
>>
>>
(Continue reading)

Permalink | Reply |
headers
Johannes Brunen | 4 Sep 10:53

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

Hello Jurko,

"Jurko Gospodnetic" <jurko.gospodnetic <at> docte.hr> schrieb im Newsbeitrag
news:<g9neff$v6f$1 <at> ger.gmane.org>...

>   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?

Below you can find a excerpt of the stlports user config file. I do not
use the stlport so maybe someone else can give more profound info.

>   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.

Currently, I favor design B.

> --------
> Design B
> --------
>    Improved version of the originally suggested 'Design A' allowing
for
(Continue reading)

Permalink | Reply |
headers
Ulrich Eckhardt | 8 Sep 08:20
Favicon

Re: [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.

On Wednesday 03 September 2008 22:57:20 Jurko Gospodnetić wrote:
> [...] MSVC compiler versions 8.0 & above.

Sorry for the rant to follow, but please erase that term from your head. The 
problem with that term is that it doesn't help at all, it is rather a 
dangerous form of half-knowledge.

Now, what's the issue? The issue is that MS versions their compilers 
independently from the IDE's they ship it with. That means that VC8 actually 
includes version 13 of their compiler. Or, rather, of their compiler_S_, 
because they support more than one target platform. Also, those target 
platforms are not just win32 and now recently the Intel and AMD 64 bit 
platforms, but also a handful of platforms for embedded use (MIPS, SH, 
ARM..). Further, they don't only ship that compiler with VC, but also with a 
tool called "Platform Builder", which allows you to select components for a 
CE OS and assemble/compile those into a bootable image. Lastly, the question 
what associated stdlib is used is independent of the compiler, e.g. 
that 'secure STL' you are writing about may or may not be available under 
CE - the compiler version doesn't tell you.

As far as your initial RFC goes, I haven't looked too deeply at it, but if 
anything important comes up I'll add that. Otherwise, I'm all for activating 
the diagnostic mode optionally.

cheers!

Uli
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |

Gmane