search for: _crt_secure_no_deprecate

...ng C4996: 'strcpy' was declared deprecated 5> c:\program files\microsoft visual studio 8\vc\include\string.h(73) : see declaration of 'strcpy' 5> Message: 'This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help for details.' 5>c:\greenhouse\workspace\soundio\tool\flac_1.1.3\main\flac-1.1.3\src\share\grabbag\cuesheet.c(251) : warning C4996: 'stricmp' was declared deprecated 5> c:\program files\microsoft visual studio 8\vc\include\string.h(213) : see declaration...

_CRT_SECURE_NO_DEPRECATE is new for VS2005. Nothing I can do with it in VS2003. Morten Ofstad wrote: > Jeff Cohen wrote: > >> The project files need frequent updating. I cannot maintain VS2005 >> project files, so while they could be distributed with LLVM, they >> will become broken fast. Al...

The new property manager doesn't exist in VS2003 either. Don't know where to add it. Chris Lattner wrote: > On Fri, 27 Jan 2006, Jeff Cohen wrote: > >> _CRT_SECURE_NO_DEPRECATE is new for VS2005. Nothing I can do with it >> in VS2003. > > > It shouldn't hurt to define it though, even if VC2003 where it does > nothing. Right? > > -Chris > >> Morten Ofstad wrote: >> >>> Jeff Cohen wrote: >>> >>>>...

...n will need to explain what to do in VS2003 to make VS2005 happy. Chris Lattner wrote: > On Fri, 27 Jan 2006, Jeff Cohen wrote: > >> The new property manager doesn't exist in VS2003 either. Don't know >> where to add it. > > > Isn't there a place to add -D_CRT_SECURE_NO_DEPRECATE for the > preprocessor? Isn't this all we are talking about, or am I missing > something? > > -Chris > >>> On Fri, 27 Jan 2006, Jeff Cohen wrote: >>> >>>> _CRT_SECURE_NO_DEPRECATE is new for VS2005. Nothing I can do with >>>> it in V...

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.

On Fri, 27 Jan 2006, Jeff Cohen wrote: > _CRT_SECURE_NO_DEPRECATE is new for VS2005. Nothing I can do with it in > VS2003. It shouldn't hurt to define it though, even if VC2003 where it does nothing. Right? -Chris > Morten Ofstad wrote: > >> Jeff Cohen wrote: >> >>> The project files need frequent updating. I cannot mai...

On Fri, 27 Jan 2006, Jeff Cohen wrote: > The new property manager doesn't exist in VS2003 either. Don't know where to > add it. Isn't there a place to add -D_CRT_SECURE_NO_DEPRECATE for the preprocessor? Isn't this all we are talking about, or am I missing something? -Chris >> On Fri, 27 Jan 2006, Jeff Cohen wrote: >> >>> _CRT_SECURE_NO_DEPRECATE is new for VS2005. Nothing I can do with it in >>> VS2003. >> >> >> It...

...ll > become broken fast. Also, VS2003 and VS2005 project and solution files > cannot coexist in the same directories, further complicating matters. The VS2003 project files convert without problems -- you might want to add in a property sheet (using the new property manager) that defines _CRT_SECURE_NO_DEPRECATE, though. Actually the VS2005 project files are XML and not that different from the VS2003 files, so just using CVS you will pick up any changes to the VS2003 files. In conclusion there is no need for separate VS2005 project files. m.

The project files need frequent updating. I cannot maintain VS2005 project files, so while they could be distributed with LLVM, they will become broken fast. Also, VS2003 and VS2005 project and solution files cannot coexist in the same directories, further complicating matters. Aaron Gray wrote: > Hi Morten, > > If you can make the VS2005 project files availiable on the net then I

...> I don't know. If that's all it was, why is there a special new property > manager to set it? Morten will need to explain what to do in VS2003 to > make VS2005 happy. IMHO all you need to do is go to Project properties -> C/C++ -> Preprocessor definitions and add _CRT_SECURE_NO_DEPRECATE Best regards, Oleg.

...s not support default-int llvm\Object\COFF.h 52 All the errors are reported in LLVM header files, mostly llvm/Support/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...

...wanadoo.es> wrote: > /* 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...

...trcpy, 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( -wd4146 -wd4503 -wd4996 -wd4800 -wd4244 -wd4624 ) add_definitions( -wd4355 -wd4715 ) endif( MSVC ) > In addition to those, fo...

Hi all, I am Sahana. I am currently working on Libtheora for windows platform and very new to it. I am getting a lot of compiling errors. Since Libtheora depends on libogg and libvorbis i have added these as well to my workspace in VC++ 6. I have a doubt regarding the x86 and x86_vc folders described in the libtheora software.Since both these folders have the same set of files which one do we

>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