No effect of "define _CRT_SECURE_NO_DEPRECATE 1"

No effect of "define _CRT_SECURE_NO_DEPRECATE 1"

• Reckless

  Although I do like some of the new, more security friendly, replacement functions; some of them I just don't understand the reasons of the changes. Are all the deprecated functions documented somewhere along with the reasons they have been deprecated
  
  For example, I can understand sprintf, as it can cause unexplained buffer overruns, and modifying code to use sprintf_s isn't exactly difficult. However, I fail to see why functions such as "fopen" have been changed the way they have. It takes a standard string, and returns a null if it failed - whats wrong with that
  
  Perhaps in a later version of the compiler we can choose which functions to generate warnings on, and which to ignore
  
  

• John Ferguson

  Hi

  We also have this problem.  Even putting as described in stdafx.h doesn't seem to work for me.  I'd be grateful for ther ideas. 

  MS don't seem to appreciate that you can't just hack thousands of lines of code to meet there latest non-standard inventions.  Surely the deprecation should be an option rather than the default.

  Cheers

  Rob

   

  
  

• Jagan P

  Hi man,
  I got the same problem when switching to VS2005 with project compiled previously in VS2003.
  
  You must define #define _CRT_SECURE_NO_DEPRECATE 1 somewhere at the very begining of any inclusions. That is, you must define this in "sdafx.h" right after #pragma once statement.
  
  Rebuild your application then everything will be just fine.
  
  If you still are confused and need help feel free to contact me by email.
  
  Kind regards,
  Claudiu-Teodor Burdulea
  

• Raybritton

  i think the solution is:
  1. right click the project name in solution explorer, then click properties
  2. go to "Configuration Properties" --> "C/C++" --> "Command Line"
  3. In "Additional options" textbox enter the folowing text
  /D "_CRT_SECURE_NO_DEPRECATE"
  
  
  using this method u define things via the compiler command line interface.
  when i used the define with 1 it didn't work, don't know why, but the above worked for me
  
  

• KatyG

  The point is that MS are effectively declaring "POSIX bad". Well I've got news for them. It's not their call.

  I am sometimes involved in situations where I need to compile code that I don't own, sometimes contributing modifications back to a greater whole. I don't own the whole. However, I need to compile the whole during testing etc. The owners of the whole use a lot of POSIX code and as one of them put it, if you are going to deprecate strcpy and fdopen, you might as well deprecate C.

  Some of these things have no one-master-include-file, included by EVERY source file, into which I can bung those two macros. Sure it sucks, but that's what programmers in the REAL world have to deal with. Legacy code not their own, as part of a loose team or group, that has to have portability.

  The point is that under no circumstances should a new version of a compiler break* code that has worked well for years. You cannot even disable the warnings at solution level, you have to do it for each project. It should be available as an option in the program, by that I mean a global option in Tools|Options**, not just a project/solution option. As an example of good practice, GCC is littered with options and manifests concering standards compliance, as part of the command-line options.

  * Yes. technically it doesn't "break" the code but (a) other changes do (e.g., enforced manifests can do this, experienced this myself) and (b) thousands of warnings, that in the context are irrelevant, mean that the code is effectively uncompilable. I wouldn't mind ONE single warning at the bottom of the output window, but object strongly to being warned of every single instance littered among any other, important warnings: i.e., warnings that might actually mean that something is actually wrong.

  ** Anticipating a flood of "oh, that encourages bad practices", well TOUGH! It is not for anybody to complain to another that having such a thing is "wrong". Many programmers do not get to choose what is "right" or "wrong" where they work, but have to live with what "is". In an ideal world, every organisation would have the time and money to invest in modifying thousands of lines of legacy code, the luxury of only having MS compilers to support, or both.

  Unfortunately, this is not an ideal world.

  
  

• Mr. Furious

  I'll answer my own question - you also need to add the undocumented _CRT_NONSTDC_NO_DEPRECATE

  with both these in the stdafx.h it does now work

  #define _CRT_SECURE_NO_DEPRECATE 1

  #define _CRT_NONSTDC_NO_DEPRECATE 1

  Rob

   

  
  

• jlewis99

  This thread belongs in the C/C++ forum, where I found the answer.
  
  
  

• Rahul Garg

  EXCELLENT TIP! Thanks Duke :)
  
  Worked like a charm.
  
  

• Jim Daubert

  so i've tried everything, adding at the top of my globaly included .h file:

  #define _CRT_SECURE_NO_DEPRECATE 1

  #define _CRT_NONSTDC_NO_DEPRECATE 1

  and also tried

  1. right click the project name in solution explorer, then click properties
  2. go to "Configuration Properties" --> "C/C++" --> "Command Line"
  3. In "Additional options" textbox enter the folowing text
      /D "_CRT_SECURE_NO_DEPRECATE"

  And i still get these warnings, and much more, like this:

  C:\Program Files\Microsoft Visual Studio 8\VC\include\cstdio(33) : warning C4995: 'gets': name was marked as #pragma deprecated

  C:\Program Files\Microsoft Visual Studio 8\VC\include\cstdio(37) : warning C4995: 'sprintf': name was marked as #pragma deprecated

  C:\Program Files\Microsoft Visual Studio 8\VC\include\cstdio(40) : warning C4995: 'vsprintf': name was marked as #pragma deprecated

  C:\Program Files\Microsoft Visual Studio 8\VC\include\cstring(20) : warning C4995: 'strcat': name was marked as #pragma deprecated

  C:\Program Files\Microsoft Visual Studio 8\VC\include\cstring(21) : warning C4995: 'strcpy': name was marked as #pragma deprecated

  C:\Program Files\Microsoft Visual Studio 8\VC\include\cwchar(34) : warning C4995: 'swprintf': name was marked as #pragma deprecated

  C:\Program Files\Microsoft Visual Studio 8\VC\include\cwchar(35) : warning C4995: 'vswprintf': name was marked as #pragma deprecated

  C:\Program Files\Microsoft Visual Studio 8\VC\include\cwchar(37) : warning C4995: 'wcscat': name was marked as #pragma deprecated

  C:\Program Files\Microsoft Visual Studio 8\VC\include\cwchar(39) : warning C4995: 'wcscpy': name was marked as #pragma deprecated

   

  And now I'm getting errors like this:

  non-class template has already been declared as a class template

  Where all I'm doing is having a class that has a friend templated class in it's private section:

  template <typename T>

  class A: public B<T>

  { }

  class C: public D

  {

  private:

  friend class A;

  }

   

  So... what the heck...  guess i'll just resort to pragma warning suppression...  kind of annoying how microsoft updates things and doesn't clearly explain what changes you will encounter and how to resolve them...  hell, why should we be forced to resolve anything...  should just work.  if you want to tell people about something more secure... throw up some news about it somewhere for someone to read who actually really cares.

  like moving DIrectSound to the PSDK was just insane to figure out.  for one thing newer PSDK is labeled "Microsoft Platform SDK for Windows Server 2003 SP1"...  so people running other OS like XP, instantly assume this download is not for them... when once you download it, it then lets you know that, "oh yeah, this works for XP also".  and it's still in my start folder labeled as "Microsoft Platform SDK for Windows Server 2003 SP1"...  weirdness...  and very frustrating....  and a BIG waste of time.  i should be compensated for loss of productivity o.O

  
  

• spoly

  I disagree. I want to opt out. I have old code that I opt out on and I am going to try to write all my new code without the opt out. This helps more developers accept the default and get warnings when useing deprecated code. These are just warnings so if you can't figure out how to define _CRT_SECURE_NO_DEPRECATE to opt out you can still build and run.

  I hope the c and c++ standards committies are looking into the new functions and deprecating the old (or at least there own new functions if not MS).

  Sorry, I will get off my soap box before I slip off...

  SLDR
  (Stephen L. De Rudder)

  
  

• zullu

  Hi Rob D,
  
  The "answer" link I posted in one of my posts above links to another post that mentions this...I used these defines when I was porting as well.
  
  
  
  

• Randy Focht

  Rob D wrote:

  MS don't seem to appreciate that you can't just hack thousands of lines of code to meet their latest non-standard inventions. Surely the deprecation should be an option rather than the default.

  Agreed. We have 100's of thousand lines of in-house code, and legacy products we need to support. This has just got in the way of development.

  A preprocessor definition to turn it off is the only reasonable option we have. It would have been nicer to have the 'opt in' rather than 'opt out'.

  
  

• Manoj Bandgar

  Defining "_CRT_SECURE_NO_DEPRECATE" via the project settings was my first thing I tried and it still did not work for me either. Later I realized, why. If you had projects in earlier versions of Visual Studio and you converted it to a newer version e.g from VC6 to VC7, your project level settings were converted to file settings and $(NoInherit) was added to them, so that file level settings now do not inherit the project level settings, hence adding the definition on the project level will have no effect. The best way is to edit the project files manually and remove all the file level settings, which are not absolutely required, then to add these definitions again on the project level. Doing so solved the problem for me.
  

• Rob Sumsion

  Hi

  We also have this problem.  Even putting as described in stdafx.h doesn't seem to work for me.  I'd be grateful for ther ideas. 

  MS don't seem to appreciate that you can't just hack thousands of lines of code to meet their latest non-standard inventions.  Surely the deprecation should be an option rather than the default.

  Cheers

  Rob

   

  
  
• No effect of "define _CRT_SECURE_NO_DEPRECATE 1"