Why is strdup() deprecated in VS 2005?

Why is strdup() deprecated in VS 2005?

• SillaS

  This functions are not secure, because they may be missused and can cause buffer overflows...
  I can not imagine why strdup is unsafe, because it will just duplicate a string but AFAIK all string functions that are only \0 terminated are declared deprecated.
  
  Just disable the warning with /wd4996 and its ok.
  
  I do not really care about this...
  
  

• S Robbins

  Thanks, Willy!  Much appreciated.
  

• sudev

  That's true: neither strdup() nor stricmp() are ANSI.  Never have been, and probably never will be.  But why deprecate them now
  

• Gho5tFac3

  PS: while strdup() isn't ANSI, it's certainly not Microsoft-specific.  I've used a lot of compilers, and I've never seen one that didn't support strdup().
  

• slodaddy

   

  "anonymous@discussions..microsoft.com" <jedediah@discussions.microsoft.com> wrote in message news:ea689efc-2e67-47f4-9fab-70132d47cbbd_WBRev1_@discussions..microsoft.com...

  This post has been edited either by the author or a moderator in the Microsoft Forums: http://forums.microsoft.com strcpy is also deprecated so out goes that theory
  
  if you're going to deprecate strcpy you might as well deprecate C

   

  strcpy() and other unsafe string functions are deprecated in favor of the alternate ANSI/ISO Secure Library fuctions.

  For more info on this Secure Library check the www.open-std.org WG14 document - ISO/IEC WDTR 24731

   

  Willy.

   

  
  

• Ivan Hou

  Can anyone explain to me why strdup() is now marked as deprecated in VS 2005 beta 2   I can understand exactly why RTL functions that accept a char * parameter have been deprecated, but strdup() takes a const char * - what's the problem
  

• thesaint381

  Sorry I misunderstood your reply.
  
  strdup() and stricmp() are now deprecated and have been replaced by _strdup() and _stricmp() respectively.  So all I have to do to get rid of the compiler warning is to add an underscore in front of all of these calls.  Thanks very much for your help!
  

• crmpicco

  Hi Hendrik!

  The big problem as I see it is that many of the new functions changed the number of parameters.
  This will make cross-platform development really hard if you want to support the new api. Imagine having two versions of your code for Windows vs. "rest of the compilers out there".
  I am not even sure you can fix all of this with macros. You probably can but it will take you alot of time to patch your code to work with it.
  

  Yes. This is a problem. The best would be if MS would standardize these new functions!
  

  -- 
  Greetings
   Jochen
   
    My blog about Win32 and .NET
    http://blog.kalmbachnet.de/

  
  

• gshad37

   

  "anonymous@discussions..microsoft.com" <hyslopc@discussions.microsoft.com> wrote in message news:d404ee6a-5fce-47f1-82f8-88a72287a797@discussions.microsoft.com...

  PS: while strdup() isn't ANSI, it's certainly not Microsoft-specific.  I've used a lot of compilers, and I've never seen one that didn't support strdup().

   

  I didn't say strdup() is Microsoft specific, I said it's not a Standard C Library function that's why it's deprecated (the standard reserves all functions starting with str) and replaced by _strdup() which IS Microsoft specific.

  Note that this is not a compiler issue it's a C Standard library issue.

   

  Willy.

   

   

  
  

• Leon Zhu

  "anonymous@discussions.microsoft.com"
  <hyslopc@discussions.microsoft.com> wrote in message
  news:25baebab-b388-4024-b75c-433b2d5c3a32_WBRev1_@discussions.microsoft.com
  > Consider the following code:    
  >
  > char * Dest = new char [ 6 ];
  >
  > strcpy(Dest, "Hello World");
  >
  > This (admittedly silly) example compiles fine but is guaranteed to
  > corrupt the heap.  Consider the new secure version:
  >
  > strcpy_s(Dest, sizeof(Dest), "Hello World");

   

  Right idea, but bad example. sizeof(Dest) is the size of the pointer and does not have anything to do with the size of the pointed-to buffer. You probably meant

   

  char Dest[ 6 ];
  
  > - this will result in Dest getting the value "Hello"

   

  Not really. Assuming 32-bit system, Dest would contain the string "Hel"
  --
  With best wishes,
      Igor Tandetnik

  
  

• jccondor

  You may not care about it, but I do.  I don't want to disable the warning because I think the concerns with most of the deprecated functions are very valid, and only wished Microsoft had done this a long time ago.  As such, I have taken the opportunity to change a lot of my code to use the new functions.  The problem is that I still call strdup(), stricmp(), and strnicmp(), which are deprecated but have no obvious replacements.  And now I am getting warnings which I have no idea how to fix (besides disabling the warning, which is not a fix IMHO).
  

• Thomas Petchel

  Ditto stricmp() - how is that unsafe, and what function should I use instead   In general it would be a great thing if the error message would include an explanation as to which function(s) should be used instead of the deprecated function.
  

• Eric W

  strcpy is also deprecated so out goes that theory
  
  if you're going to deprecate strcpy you might as well deprecate C
  
  

• caroline_h

  But that's the whole point of this thread: they are deprecated for different reasons.  The reason strcpy() (and many other functions that accept char *) are deprecated is pretty well-documented: it's because they are unsafe.  Consider the following code:
  
  char * Dest = new char [ 6 ];
  
  strcpy(Dest, "Hello World");
  
  This (admittedly silly) example compiles fine but is guaranteed to corrupt the heap.  Consider the new secure version:
  
  strcpy_s(Dest, sizeof(Dest), "Hello World");
  
  - this will result in Dest getting the value "Hello" and no heap corruption occurring.  This is why strcpy() has been deprecated in favor of strcpy_s(), sprintf() has been deprecated in favor of sprintf_s(), etc.
  
  strdup(), stricmp(), and strnicmp() have also been deprecated, and I assumed it was also related to security, but it's not.  They are deprecated simply because they are not part of the ANCI C or C++ standard, and as such should always have been prefixed by an underscore.  This was a historical mistake that Microsoft has now rectified in VS 2005.
  
  Just as an aside, Microsoft has submitted all of the new ..._s() functions to the ANSI C++ committe for inclusion into the standard.  Will be interesting to see how that goes.
  
• Why is strdup() deprecated in VS 2005?