Why is strdup() deprecated in VS 2005?

 
This post has been edited either by the author or a moderator in the Microsoft Forums: http://forums.microsoft.com 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).
 
These functions are not ANSI but Microsoft specific, so they are now prefixed with _
 
 like _strdup()
 
 
Willy.
 
 
 


Answer this question

Why is strdup() deprecated in VS 2005?

  • Athar.Iqbal

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

     
    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.
     

  • Curt Nichols

    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
  • shameel

    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().
  • Paranth

    strcpy is also deprecated so out goes that theory

    if you're going to deprecate strcpy you might as well deprecate C

  • Roygar

    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).
  • Drum Red

    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.
  • CarlosMaxx

    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...

  • ramdee

    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!

  • Polypterus

    "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

  • elmoman

    Thanks, Willy!  Much appreciated.
  • Dragon123456789

    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.

  • NASWAY

    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/

  • dannyR

     
    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.
     
     

  • Why is strdup() deprecated in VS 2005?