Displaying 9 results from an estimated 9 matches for "_secure_scl".
Did you mean:
d_secure_scl
2008 Nov 25
2
[LLVMdev] Removal of Visual Studio project files.
...nitions( -wd4146 -wd4503 -wd4996 -wd4800 -wd4244 -wd4624 )
add_definitions( -wd4355 -wd4715 )
endif( MSVC )
> In addition to those, for Release builds I recommend disabling the
> "secure" stdlib features which does bounds checking and slows down a
> lot of good code:
>
> _SECURE_SCL=0 // slow secure stdlib.
This isn't, but adding an option for just one define does not save any
work.
--
Oscar
2008 Nov 25
0
[LLVMdev] Removal of Visual Studio project files.
...t; /* snip */
Thanks so much for that information. :)
For note, this is my usual line I add to the end of my preprocessor
definitions in *every* single project I ever open now (thanks to some
very bad memories associated with not having them).
;_CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_DEPRECATE;_SECURE_SCL=0;_SCL_SECURE_NO_DEPRECATE;_HAS_ITERATOR_DEBUGGING=0
Most of those will be obvious, but as stated, both _SECURE_SCL and
_HAS_ITERATOR_DEBUGGING (especially this last one, you can 'sometimes'
get by with linking on just _SECURE_SCL, but not with
_HAS_ITERATOR_DEBUGGING for some forsaken rea...
2008 Nov 25
0
[LLVMdev] Removal of Visual Studio project files.
...d get exploited with. Turn them off with these:
_CRT_SECURE_NO_WARNINGS // C deprecation
_SCL_SECURE_NO_WARNINGS // C++ deprecation
In addition to those, for Release builds I recommend disabling the
"secure" stdlib features which does bounds checking and slows down a
lot of good code:
_SECURE_SCL=0 // slow secure stdlib.
--
Cory Nelson
http://www.int64.org
2008 Nov 25
2
[LLVMdev] Removal of Visual Studio project files.
OvermindDL1 <overminddl1 at gmail.com> writes:
>> Chris proposed on IRC to remove the Visual Studio project files and turn
>> CMake into the "standard" for building LLVM with VC++.
>>
>> If you have strong arguments against this, please voice them.
>
> As long as instructions are supplied on how to pass in user defined
> macros to the build system.
2010 Mar 06
0
[LLVMdev] [PATCH]: MSVC build enhancements
...gmail.com> writes:
> Attached are two patches with MSVC build enchancements.
>
> They are quite trivial, but were necessary to correctly link LLVM
> libraries with Mesa3D on Windows.
[snip]
> add_llvm_definitions( -D_SCL_SECURE_NO_DEPRECATE )
> + add_llvm_definitions( -D_SECURE_SCL=0 )
With this setting the default LLVM build becomes incompatible with
libraries compiled with _SECURE_SCL=1 (which is the default
setting). The right thing here is to use an option.
> - add_llvm_definitions("/${LLVM_USE_CRT}")
> + # http://www.cmake.org/Wiki/CMake_FAQ#How_c...
2008 Dec 07
0
[LLVMdev] Build errors on trunk for about a week now.
...you need it (I
>> built no other configurations beyond debug).
>
> Your INCLUDE and LIB environment variables contains lots of stuff that
> may be interfering with the build. Please try after removing all
> third-party libraries from those variables.
>
> You can try removing _SECURE_SCL and _HAS_ITERATOR_DEBUGGING from the
> defines too. You define them to 0, which may be not a good idea, as that
> produces different results depending on how you test the variable (with
> #ifdef or with #if).
I finally got some time to where I could delve into things. First,
let me say i...
2010 Mar 06
6
[LLVMdev] [PATCH]: MSVC build enhancements
Attached are two patches with MSVC build enchancements.
They are quite trivial, but were necessary to correctly link LLVM
libraries with Mesa3D on Windows.
Jose
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Allow-to-build-against-static-MSVC-runtime.patch
Type: text/x-patch
Size: 2055 bytes
Desc: not available
URL:
2010 Mar 06
4
[LLVMdev] [PATCH]: MSVC build enhancements
...but were necessary to correctly link LLVM
>> libraries with Mesa3D on Windows.
>>
>> Jose
>>
>
> Are you volontary trying to break everyone build (just to build your own
> project), or have you no idea of the effect of this change:
>
> +add_llvm_definitions( -D_SECURE_SCL=0 )
>
> While I personnaly use this flag in all my projects, it should not be
> silently and sneakily imposed to all llvm user. You should make it an
> option, and keep the default as it is currently. I.e. make this an opt-in
> choice.
>
> While I may seem harsh, this flag chan...
2008 Dec 05
4
[LLVMdev] Build errors on trunk for about a week now.
I did some looking up on that const thing. Apparently that const is
'supposed' to be there, but it is not strictly required. However
there is a bug in VS2k3 (VS7) through VS2k8 (VS9) (no clue if it has
been fixed yet) that requires it to be there when the functor is being
called through a const qualified interface, such as through stl
containers. They state that a bug report has been