search for: _scl_secure_no_warnings

...namicLibrary.inc - ELM_Callback is declared with a PSTR ModuleName argument. This causes a compile error - the callback typedef specifies PCSTR. Also, I'd like to suggest adding the following to config.h, to eliminate the spurious deprecation warnings: #define _CRT_SECURE_NO_WARNINGS #define _SCL_SECURE_NO_WARNINGS #define _CRT_NONSTDC_NO_WARNINGS And moving #include "llvm/Config/config.h" in all the files above any other includes, so those will have the proper effect. Finally, is the JIT considered stable under Windows? -- Cory Nelson

> Also, I'd like to suggest adding the following to config.h, to > eliminate the spurious deprecation warnings: > > #define _CRT_SECURE_NO_WARNINGS > #define _SCL_SECURE_NO_WARNINGS > #define _CRT_NONSTDC_NO_WARNINGS > > > And moving #include "llvm/Config/config.h" in all the files above any > > other includes, so those will have the proper effect. Can we guard those defines like so? #if defined _MSC_VER && _MSC_VER >= 1300 #if !d...

Razvan Aciu wrote: > As I saw from the mailing list the MSVC 2005 patches were made to take into > account the new files from the development branch, files which are not in > the 2.3 release. So for now the below patch is the only one functional for > the release. If I am wrong, please someone correct me. > > If someone can make a 2005 patch for the release branch, it is ok.

...when building LLVM 2.1 in VC++ 2005. You might want to try LLVM SVN. I believe Hartmut has made several improvements. > Also, I'd like to suggest adding the following to config.h, to > eliminate the spurious deprecation warnings: > > #define _CRT_SECURE_NO_WARNINGS > #define _SCL_SECURE_NO_WARNINGS > #define _CRT_NONSTDC_NO_WARNINGS > > And moving #include "llvm/Config/config.h" in all the files above any > other includes, so those will have the proper effect. If LLVM SVN doesn't have these improvements, please consider sending in a patch, thanks! > Finally, is...

...or enabling them all > with a single -D cmake option. > He's talking about how VC++ deprecated (with warnings) many C/C++ functions (like strcpy, sprintf, std::copy, etc.) that a dumb developer could 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

...t/COFF.h and llvm/Object/COFF.h I'm using Visual Studio Community 2015, the CXX compiler identification is MSVC 19.0.23026.0 My CPP includes are: WIN32 _WINDOWS NDEBUG _CRT_SECURE_NO_DEPRECATE _CRT_SECURE_NO_WARNINGS _CRT_NONSTDC_NO_DEPRECATE _CRT_NONSTDC_NO_WARNINGS _SCL_SECURE_NO_DEPRECATE _SCL_SECURE_NO_WARNINGS __STDC_CONSTANT_MACROS __STDC_FORMAT_MACROS __STDC_LIMIT_MACROS _GNU_SOURCE %(PreprocessorDefinitions) Now, a couple of things are suspicious: - in googling around it seems like there are some problems with including Windows.h (which I have to include for other reasons) as well as the LLVM heade...

...:\[top-level-dir]\[dest-dir]\[dest-sub-dir]\include /IC:\[SDK-dir]\[SDK-source-dir]\[SDK-sub-dir]\include /IC:\[SDK-dir]\[SDK-source-dir]\[SDK-sub-dir]\include\[include-sub-dir] /Zi /nologo /W3 /WX- /Od /D WIN32 /D _DEBUG /D _WINDOWS /D _USRDLL /D [elided] /D _t_env_os_WIN32 /D [also-elided] /D _SCL_SECURE_NO_WARNINGS /D _CRT_SECURE_NO_WARNINGS /D OBJC_OLD_DISPATCH_PROTOTYPES=1 /D _WIN64 /D "__x86_64__= 1" /D _WINDLL /D _UNICODE /D UNICODE /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"Debug\x64\\" /Fd"Debug\x64\vc120.pdb" /Gd /TP /wd4068 /wd4200 /wd4244 /wd4...

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.

...Later on, I get an error saying that crtdefs.h is trying to redefine >> size_t from an unsigned int to an unsigned long long... >> >> Perhaps one of my preprocessor defines is causing these errors: >> >> WIN32 >> _DEBUG >> _WINDOWS >> _USRDLL >> _SCL_SECURE_NO_WARNINGS >> _CRT_SECURE_NO_WARNINGS >> _WIN64 >> _x86_64_ = 1 >> >> (I added the "SECURE_NO_WARNINGS" defines when I ported an earlier >> version of this code to VS 2005; don't remember why any more...) >> (There are a couple of other defines that are...

...~~~~~~~~~~~~~~~~~~~ > > Later on, I get an error saying that crtdefs.h is trying to redefine > size_t from an unsigned int to an unsigned long long... > > Perhaps one of my preprocessor defines is causing these errors: > > WIN32 > _DEBUG > _WINDOWS > _USRDLL > _SCL_SECURE_NO_WARNINGS > _CRT_SECURE_NO_WARNINGS > _WIN64 > _x86_64_ = 1 > > (I added the "SECURE_NO_WARNINGS" defines when I ported an earlier version > of this code to VS 2005; don't remember why any more...) > (There are a couple of other defines that are specific to the DLL I'm...

Hi Reid, I copied the x64 toolsets by hand; they got installed to C:\Program Files (x86)\LLVM\tools\msbuild\x64; they just didn't get moved correctly by install.bat. I just verified that the LLVM-vs2013 toolset.props is correct. If it is a bitness problem, perhaps I'm failing to define something correctly? Regards, Eric On 9/30/14, 11:29 AM, Reid Kleckner wrote: > This looks

...gt;> be great. >> [snip] > He's talking about how VC++ deprecated (with warnings) many C/C++ > functions (like strcpy, sprintf, std::copy, etc.) that a dumb > developer could get exploited with. Turn them off with these: > > _CRT_SECURE_NO_WARNINGS // C deprecation > _SCL_SECURE_NO_WARNINGS // C++ deprecation > Those and others already are defined by default: if( MSVC ) add_definitions( -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS ) add_definitions( -D_SCL_SECURE_NO_WARNINGS -DCRT_NONSTDC_NO_WARNINGS ) add_definitions( -D_SCL_SECURE_NO_DEPRECATE ) add_definitions(...

...w(size_t,unsigned int)' : no matching operator delete found; memory will not be freed if initialization throws an exception f:\Prog\llvm\include\llvm/User.h(230) : see declaration of 'llvm::User::operator new' and the project files lack some preprocessor definitions: there is _SCL_SECURE_NO_WARNINGS, but it only work with SP1, we need _SCL_SECURE_NO_DEPRECATE for vanilla VS2005 -- Cédric

>There's a config.h file in the win32 subdirectory that implies that it's >supposed to be concatenated as part of the build process, but it doesn't >seem like that's happening from within the .sln script--am I missing a >pre-build step someplace? When config.h.in is hit in the build of configure the configure project, the configure.h file from the win32 directory is