|
|
12
|
|
Dear all,
Is there are reason why we do not compile with this flag set by default?
Are there any users of Boost out there which actually wants the securuty
mode turned on?
If not, then I suggest that we change the build settings.
Thanks in advance
-Thorsten
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
|
Thorsten,
On Thu, Dec 4, 2008 at 3:05 PM, Thorsten Ottosen <
[hidden email]> wrote:
> Dear all,
>
> Is there are reason why we do not compile with this flag set by default?
> Are there any users of Boost out there which actually wants the securuty
> mode turned on?
>
I personally prefer to have _SECURE_SCL=0 in Release builds too. For users
that also have to build against other libraries that are provided as
precompiled binaries that use the MSVC defaults this would break things. The
_SECURE_SCL setting changes the ABI.
>
> If not, then I suggest that we change the build settings.
>
I think it would be ok to allow both options, but probably the default
should equal the Microsoft default with an easy way to opt-out of the
madness!
>
> Thanks in advance
>
> -Thorsten
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost>
HTH,
Neil Groves
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
|
Neil Groves skrev:
> Thorsten,
>
> On Thu, Dec 4, 2008 at 3:05 PM, Thorsten Ottosen <
> [hidden email]> wrote:
>
>> Dear all,
>>
>> Is there are reason why we do not compile with this flag set by default?
>> Are there any users of Boost out there which actually wants the securuty
>> mode turned on?
>>
>
> I personally prefer to have _SECURE_SCL=0 in Release builds too. For users
> that also have to build against other libraries that are provided as
> precompiled binaries that use the MSVC defaults this would break things. The
> _SECURE_SCL setting changes the ABI.
>
>
>> If not, then I suggest that we change the build settings.
>>
>
> I think it would be ok to allow both options, but probably the default
> should equal the Microsoft default with an easy way to opt-out of the
> madness!
But AFAIK, even the prebuilt binaries that you get from Boost Consulting
are built with _SECURE_SCL=0.
-Thorsten
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
|
Thorsten Ottosen wrote:
>>> I think it would be ok to allow both options, but probably the
>>> default should equal the Microsoft default with an easy way to
>>> opt-out of the madness!
Agree 100%, our default should equal the compiler default, otherwise it'll
catch too many folks out.
>> But AFAIK, even the prebuilt binaries that you get from Boost
>> Consulting are built with _SECURE_SCL=0.
Really ??? I hadn't realised that, that's not good IMO, given that the
define changes the ABI away from the compilers default.
One thing I hope we can all agree on: this should be a toolset feature, and
it should change the library-name-mangling so that auto_link.hpp can select
the correct binary (it doesn't at present, but just let me know what the
correct name-mangling is and I'll fix that).
John.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
|
>> But AFAIK, even the prebuilt binaries that you get from Boost
>> Consulting are built with _SECURE_SCL=0.
>
> Really ??? I hadn't realised that, that's not good IMO, given
> that the define changes the ABI away from the compilers default.
> One thing I hope we can all agree on: this should be a toolset
> feature, and it should change the library-name-mangling so
> that auto_link.hpp can select the correct binary (it doesn't
> at present, but just let me know what the correct name-mangling
> is and I'll fix that).
There have been a few discussions in the past on this, see this little
research and proposal I did a few weeks ago:
http://www.nabble.com/MSVC-_SECURE_SCL-causes-ABI-change%2C-ODR-violation---mangle-library-names--td19919013.html#a19919013
JF
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
|
John Maddock skrev:
> Thorsten Ottosen wrote:
>>>> I think it would be ok to allow both options, but probably the
>>>> default should equal the Microsoft default with an easy way to
>>>> opt-out of the madness!
>
> Agree 100%, our default should equal the compiler default, otherwise
> it'll catch too many folks out.
>
>>> But AFAIK, even the prebuilt binaries that you get from Boost
>>> Consulting are built with _SECURE_SCL=0.
>
> Really ??? I hadn't realised that, that's not good IMO, given that the
> define changes the ABI away from the compilers default.
Dave, since its your company that prevides the binary, can you comment
on this?
-Thorsten
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
|
on Fri Dec 05 2008, Thorsten Ottosen <thorsten.ottosen-AT-dezide.com> wrote:
> John Maddock skrev:
>> Thorsten Ottosen wrote:
>>>>> I think it would be ok to allow both options, but probably the
>>>>> default should equal the Microsoft default with an easy way to
>>>>> opt-out of the madness!
>>
>> Agree 100%, our default should equal the compiler default, otherwise it'll catch too
>> many folks out.
>>
>>>> But AFAIK, even the prebuilt binaries that you get from Boost
>>>> Consulting are built with _SECURE_SCL=0.
>>
>> Really ??? I hadn't realised that, that's not good IMO, given that the define
>> changes the ABI away from the compilers default.
>
> Dave, since its your company that prevides the binary, can you comment on this?
Our binaries are built the standard way that bjam makes them. We don't
do anything special to add _SECURE_SCL=0.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
|
I don't have any experience with bjam and so on. But I think it would be
a good idea to provide libraries with and without _SECURE_SCL (and
different library name). If I can do some work for that..
David Abrahams schrieb:
> on Fri Dec 05 2008, Thorsten Ottosen <thorsten.ottosen-AT-dezide.com> wrote:
>
>> John Maddock skrev:
>>> Thorsten Ottosen wrote:
>>>>>> I think it would be ok to allow both options, but probably the
>>>>>> default should equal the Microsoft default with an easy way to
>>>>>> opt-out of the madness!
>>> Agree 100%, our default should equal the compiler default, otherwise it'll catch too
>>> many folks out.
>>>
>>>>> But AFAIK, even the prebuilt binaries that you get from Boost
>>>>> Consulting are built with _SECURE_SCL=0.
>>> Really ??? I hadn't realised that, that's not good IMO, given that the define
>>> changes the ABI away from the compilers default.
>> Dave, since its your company that prevides the binary, can you comment on this?
>
> Our binaries are built the standard way that bjam makes them. We don't
> do anything special to add _SECURE_SCL=0.
>
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
|
On Fri, 19 Dec 2008 11:07:53 +0100, Hansi < [hidden email]> wrote:
> I don't have any experience with bjam and so on. But I think it would be
> a good idea to provide libraries with and without _SECURE_SCL (and
> different library name). If I can do some work for that..
I think it's just a question of writing the right config for bjam.
--
EA
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
|
I will check it..but I have no experience with bjam...I think it is
really important because it is a ABI change!!!
Edouard A. schrieb:
> On Fri, 19 Dec 2008 11:07:53 +0100, Hansi < [hidden email]> wrote:
>> I don't have any experience with bjam and so on. But I think it would be
>> a good idea to provide libraries with and without _SECURE_SCL (and
>> different library name). If I can do some work for that..
>
> I think it's just a question of writing the right config for bjam.
>
>
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
|
> I will check it..but I have no experience with bjam...I think it is
> really important because it is a ABI change!!!
I'm not sure but I think you can do something like bjam
cxxflags=-D_SECURE_SCL=0
--
EA
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
|
It is important that we get another name for the library! similar to the
debug libraries or mulithreading libraries...
Edouard A. schrieb:
>> I will check it..but I have no experience with bjam...I think it is
>> really important because it is a ABI change!!!
>
> I'm not sure but I think you can do something like bjam
> cxxflags=-D_SECURE_SCL=0
>
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
|
On Fri, 19 Dec 2008 14:23:08 +0100, Hansi < [hidden email]> wrote:
> It is important that we get another name for the library! similar to the
> debug libraries or mulithreading libraries...
Then you need to write a new configuration.
--
EA
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
|
I have to agree with this. Another boost configuration that disables
all that Microsoft crap that slows down code for no good reason would
be wonderful. I personally build Boost myself with this command (in a
batch file):
..\bjam --build-type=complete --toolset=msvc-8.0 --without-mpi
--prefix=R:/SDKs/boost/built_head --build-dir=R:/SDKs/boost/build_head
define=_CRT_NONSTDC_NO_DEPRECATE define=_CRT_SECURE_NO_DEPRECATE
define=_SECURE_SCL=0 define=_SCL_SECURE_NO_DEPRECATE
define=_HAS_ITERATOR_DEBUGGING=0 install>..\build-HEAD.log
I compile everything I ever get that even touches the STL with the
above defines, else nice crashes abound.
But for an example, a parser I made with Boost.Spirit took 5 minutes
without the above defines, took 5 second with them (times are pretty
accurate, it was a massive difference), that is how utterly crappy the
STL implementation is in VS2k5 and higher without those.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
|
On Fri, Dec 19, 2008 at 9:36 AM, OvermindDL1 < [hidden email]> wrote:
> I have to agree with this. Another boost configuration that disables
> all that Microsoft crap that slows down code for no good reason would
> be wonderful. I personally build Boost myself with this command (in a
> batch file):
>
> ..\bjam --build-type=complete --toolset=msvc-8.0 --without-mpi
> --prefix=R:/SDKs/boost/built_head --build-dir=R:/SDKs/boost/build_head
> define=_CRT_NONSTDC_NO_DEPRECATE define=_CRT_SECURE_NO_DEPRECATE
> define=_SECURE_SCL=0 define=_SCL_SECURE_NO_DEPRECATE
> define=_HAS_ITERATOR_DEBUGGING=0 install>..\build-HEAD.log
I'm not against a separate configuration that disables these things
but I'm happy with the default release the way it is; I find the STL
checks in the Microsoft implementation quite helpful. I've found that
usually I don't have any reasons to disable them.
Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
|
The checks are however a huge performance hit that people tend to be caught by surprise with.
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: "Emil Dotchevski" < [hidden email]>
Date: Fri, 19 Dec 2008 10:58:53
To: < [hidden email]>
Subject: Re: [boost] [boost.build] should we not define _SECURE_SCL=0 by
default for all msvc toolsets
On Fri, Dec 19, 2008 at 9:36 AM, OvermindDL1 < [hidden email]> wrote:
> I have to agree with this. Another boost configuration that disables
> all that Microsoft crap that slows down code for no good reason would
> be wonderful. I personally build Boost myself with this command (in a
> batch file):
>
> ..\bjam --build-type=complete --toolset=msvc-8.0 --without-mpi
> --prefix=R:/SDKs/boost/built_head --build-dir=R:/SDKs/boost/build_head
> define=_CRT_NONSTDC_NO_DEPRECATE define=_CRT_SECURE_NO_DEPRECATE
> define=_SECURE_SCL=0 define=_SCL_SECURE_NO_DEPRECATE
> define=_HAS_ITERATOR_DEBUGGING=0 install>..\build-HEAD.log
I'm not against a separate configuration that disables these things
but I'm happy with the default release the way it is; I find the STL
checks in the Microsoft implementation quite helpful. I've found that
usually I don't have any reasons to disable them.
Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
|
> I'm not against a separate configuration that disables these things
> but I'm happy with the default release the way it is; I find the STL
> checks in the Microsoft implementation quite helpful. I've found that
> usually I don't have any reasons to disable them.
I think disabling the Microsoft checks only make sense for the release
version, in debug they are indeed life savers.
--
EA
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
|
You are right there is no reason to disable them totally. But it would
be great to have the libraries with and without SECURE_SCL in parallel
so everyone could decide to switch between the 2 modes
Regards
Hansjörg
Emil Dotchevski schrieb:
> On Fri, Dec 19, 2008 at 9:36 AM, OvermindDL1 < [hidden email]> wrote:
>> I have to agree with this. Another boost configuration that disables
>> all that Microsoft crap that slows down code for no good reason would
>> be wonderful. I personally build Boost myself with this command (in a
>> batch file):
>>
>> ..\bjam --build-type=complete --toolset=msvc-8.0 --without-mpi
>> --prefix=R:/SDKs/boost/built_head --build-dir=R:/SDKs/boost/build_head
>> define=_CRT_NONSTDC_NO_DEPRECATE define=_CRT_SECURE_NO_DEPRECATE
>> define=_SECURE_SCL=0 define=_SCL_SECURE_NO_DEPRECATE
>> define=_HAS_ITERATOR_DEBUGGING=0 install>..\build-HEAD.log
>
> I'm not against a separate configuration that disables these things
> but I'm happy with the default release the way it is; I find the STL
> checks in the Microsoft implementation quite helpful. I've found that
> usually I don't have any reasons to disable them.
>
> Emil Dotchevski
> Reverge Studios, Inc.
> http://www.revergestudios.com/reblog/index.php?n=ReCode> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost>
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
|
John Maddock skrev:
> Thorsten Ottosen wrote:
>>>> I think it would be ok to allow both options, but probably the
>>>> default should equal the Microsoft default with an easy way to
>>>> opt-out of the madness!
>
> Agree 100%, our default should equal the compiler default, otherwise
> it'll catch too many folks out.
>
>>> But AFAIK, even the prebuilt binaries that you get from Boost
>>> Consulting are built with _SECURE_SCL=0.
>
> Really ??? I hadn't realised that, that's not good IMO, given that the
> define changes the ABI away from the compilers default.
>
> One thing I hope we can all agree on: this should be a toolset feature,
> and it should change the library-name-mangling so that auto_link.hpp can
> select the correct binary (it doesn't at present, but just let me know
> what the correct name-mangling is and I'll fix that).
what about adding "-nsl" (no secure library) in the name?
-Thorsten
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
12
|
Locked
