[perl #41602] [TODO] MS VS 2005 deprecates strdup

26 views
Skip to first unread message

Klaas-Jan Stol

unread,
Feb 23, 2007, 4:32:23 PM2/23/07
to bugs-bi...@rt.perl.org
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #41602]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41602 >


hi,

as of Microsoft visual studio 2005, the function 'strdup' is deprecated.

Attached is a patch fixing:

* add a file parrot/config/gen/platform/win32/string.h, checking for the
compiler; if it is MSVS 2005, strdup is defined as _strdup
* add the same file to be included, by config/gen/platform.pm

There should be more string functions deprecated. As long as Parrot
doesn't use them, they can be left out (no unnecessary #defines).

(On a personal note: I wondered for a minute if strdup should be used,
as it malloc's memory for the string, and then it's out of control of
the garbage collector. Is this an issue? I'm not familiar with memory
stuff in parrot.)

regards,
klaas-jan

strdup.patch

jnthn@jnthn.net via RT

unread,
Mar 2, 2007, 5:02:58 PM3/2/07
to perl6-i...@perl.org
Hi,

Applied in 17281, thanks.

For your question, strdup is fine since these are not garbage
collectable strings (STRING*), just normal C char*'s. There is loads of
them used in IMCC. Unfortunately though, there is an issue in that we
don't free a load of 'em, or at least hadn't used to and I doubt that's
been fixed. So that may hurt us with eval'd code in the future...

Jonathan

Klaas-Jan Stol

unread,
Mar 4, 2007, 1:01:00 PM3/4/07
to perl6-i...@perl.org
hi,
I still get the warning. On further inspection the file I added through
the patch (win32/string.h) is not added. The
#define of strdup as _strdup is in there. So, in order to resolve this
issue, the file should be added. (it's included in the original patch)

regards,
kjs

Kevin Tew

unread,
Mar 5, 2007, 10:20:07 AM3/5/07
to Klaas-Jan Stol, perl6-i...@perl.org
Defining _CRT_SECURE_NO_DEPRECATE on the compiler command line is
probably the right solution here.
Kevin

Jerry Gay

unread,
Mar 5, 2007, 10:36:56 AM3/5/07
to Kevin Tew, Klaas-Jan Stol, perl6-i...@perl.org
On 3/5/07, Kevin Tew <te...@tewk.com> wrote:
> Defining _CRT_SECURE_NO_DEPRECATE on the compiler command line is
> probably the right solution here.
> Kevin
>
i disagree. the reason C<strdup>, C<strnicmp> and C<stricmp> were
deprecated is because they're non-ansi. therefore, microsoft renamed
it to C<_strdup>. since we've pledged ansi (aka c89) c compliance, we
should be following a similar path.

instead of disabling the *valid* compiler warning, i suggest that
either we modify our coding standard to allow C<strdup>, or we rename
all usage to C<_strdup> and #define as appropriate for each compiler.

~jerry

Klaas-Jan Stol

unread,
Mar 5, 2007, 11:48:57 AM3/5/07
to jerry gay, Kevin Tew, perl6-i...@perl.org


Moreover, strdup was not deprecated without a reason; strdup is claimed to
be unsafe. It might be a good idea to accept this piece of advice, and use
_strdup and friends.

kjs

Nicholas Clark

unread,
Mar 5, 2007, 12:06:34 PM3/5/07
to Klaas-Jan Stol, jerry gay, Kevin Tew, perl6-i...@perl.org

I read that and though "huh?"

A better answer seems to be further down in:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=6995&SiteID=1


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.


IIRC ANSI have reserved every function name starting str, so this is correct.
They've also reserved every type ending _t, but it seems that few pay
attention to that either.

Nicholas Clark

Kevin Tew

unread,
Mar 5, 2007, 12:22:11 PM3/5/07
to Philip Taylor, Klaas-Jan Stol, jerry gay, perl6-i...@perl.org
I believe that VS2005 Has a new snprintf_s, strcpy_s etc that are
suppose to be secure

See:
http://msdn2.microsoft.com/en-us/library/8ef0s5kh(VS.80).aspx.
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=6995&SiteID=1.

Kevin

Philip Taylor wrote:

> As far as I can see, MSVC doesn't claim strdup is unsafe - string.h
> just defines it with "_CRT_NONSTDC_DEPRECATE", and the compiler warns
> "The POSIX name for this item is deprecated. Instead, use the ISO C++
> conformant name: _strdup. See online help for details."
>
> For the string functions which it does claim are unsafe (strcpy,
> strcat, etc), it warns "This function or variable may be unsafe.
> Consider using strcpy_s instead" and provides the _s alternatives; but
> strdup isn't one of those functions. A call to strdup is actually
> compiled into a call to _strdup (via linker tricks (I assume) in
> oldnames.lib), so there's no difference at all in implementation or
> safety.
>

Jerry Gay

unread,
Mar 5, 2007, 12:40:03 PM3/5/07
to Philip Taylor, Klaas-Jan Stol, Kevin Tew, perl6-i...@perl.org
On 3/5/07, Philip Taylor <phi...@zaynar.demon.co.uk> wrote:
> For the string functions which it does claim are unsafe (strcpy, strcat,
> etc), it warns "This function or variable may be unsafe. Consider using
> strcpy_s instead" and provides the _s alternatives; but strdup isn't one
> of those functions. A call to strdup is actually compiled into a call to
> _strdup (via linker tricks (I assume) in oldnames.lib), so there's no
> difference at all in implementation or safety.
>
strdup isn't unsafe. it just copies a string--no worries about buffer overflow.

the ansi str* functions *are* likely unsafe, and should be converted
to something safe for compilers which offer a safe alternative, like
msvc. patches to redefine str* functions to the compiler-specific
variant are most certainly welcome.

~jerry

Philip Taylor

unread,
Mar 5, 2007, 12:13:42 PM3/5/07
to Klaas-Jan Stol, jerry gay, Kevin Tew, perl6-i...@perl.org
Klaas-Jan Stol wrote on 05/03/2007 16:48:

As far as I can see, MSVC doesn't claim strdup is unsafe - string.h just

defines it with "_CRT_NONSTDC_DEPRECATE", and the compiler warns "The
POSIX name for this item is deprecated. Instead, use the ISO C++
conformant name: _strdup. See online help for details."

For the string functions which it does claim are unsafe (strcpy, strcat,

etc), it warns "This function or variable may be unsafe. Consider using
strcpy_s instead" and provides the _s alternatives; but strdup isn't one
of those functions. A call to strdup is actually compiled into a call to
_strdup (via linker tricks (I assume) in oldnames.lib), so there's no
difference at all in implementation or safety.

--
Philip Taylor
phi...@zaynar.demon.co.uk

Klaas-Jan Stol via RT

unread,
Mar 16, 2007, 9:09:05 AM3/16/07
to perl6-i...@perl.org
On Fri Mar 16 05:53:37 2007, coke wrote:
> file in original patch was never added. Added, need feedback from
> win32 developers if this addresses the warning.

No more strdup deprecation warnings.

kjs

Reply all
Reply to author
Forward
0 new messages