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
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
regards,
kjs
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
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
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
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.
>
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
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
No more strdup deprecation warnings.
kjs