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-violatio n---mangle-library-names--td19919013.html#a19919013 JF _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost |
In reply to this post by John Maddock
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 |
On Fri, Dec 19, 2008 at 10:34 PM, <[hidden email]> wrote:
> The checks are however a huge performance hit that people tend to be caught by surprise with. Not my experience. The checks do affect performance, but rarely enough to get on my radar. I do like having them on by default. 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 |
In reply to this post by Emil Dotchevski-3
> 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 |
In reply to this post by Emil Dotchevski-3
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 |
In reply to this post by John Maddock
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 |
Free forum by Nabble | Edit this page |