Re: [reSIProcate] Visual Studio 2005 compilation warnings of 1.4 branch
Adam,
I wanted to add a few more comments on the strdup issue.
strdup was not replaced by _strdup due to security concerns.
This function is never unsecure because it does not write to
an existing buffer, instead it creates and returns a new
buffer, so buffer overruns (at least) will never occur.
The reason why it was replaced is that strdup (and similar
functions) do not conform to the ISO C++ standard because
functions starting with 'str' are reserved and strdup does
not belong to the standard (at least the '99 one).
While I think it is a noble goal by MS to be more standards
compliant I think this decision is silly because it create
more cross-platform issues as it solves...
It remains interesting, though, if other compilers will
Follow this route ;-)
The other really important change to many of the string functions
is the introduction of the secure string functions, suffixed
with '_s'.
I would be interested in replacing all these functions with
their secure counterparts in the next year.
The platform compatibility could be easily achieved by creating
a few wrapper functions included in a define which will call
the unsecure counterparts on platforms where the secure versions
are available.
The benefit of this is obvious...
Does anybody know about non-Windows platforms, are there libraries
with these secure functions already?
Best regards,
Matthias Moetje
TERASENS GmbH
Augustenstraße 24
80333 Munich
GERMANY
-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Adam Roach
Sent: Dienstag, 2. Dezember 2008 18:32
To: Scott Godin
Cc: resiprocate-devel@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Visual Studio 2005 compilation warnings of 1.4 branch
Okay, after a little more digging, I think Dmitry's suggestion is
correct. _strdup() does not appear to be present on most (any?)
non-windows systems.
It would appear that the strdup() function is deprecated as being
potentially unsafe (you can get corruption in the case of unterminated
strings). It would appear that Microsoft has gone about addressing this
in a truly gonzo way: complain about the original function, but provide
an equally unsafe, identical function with an underscore prepended.
In practice, the proper solution is to replace strdup with strndup, but
that's not a mechanical operation (you need to read and understand the
code).
/a
Scott Godin wrote:
> Agreed - I just wasn't sure offhand how portable it was to change it.
>
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Adam
> Roach
> Sent: Tuesday, December 02, 2008 10:51 AM
> To: Scott Godin
> Cc: resiprocate-devel@xxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] Visual Studio 2005 compilation warnings of
> 1.4 branch
>
> Hmm... it would seem that the proper solution for #1 would be to replace
>
> strdup with _strdup everywhere.
>
> /a
>
> Scott Godin wrote:
>
>> I'll add these fixes - thanks!
>>
>> Scott
>>
>> On Tue, Dec 2, 2008 at 9:34 AM, Dmitry Semyonov <dsemyonov@xxxxxxx>
>>
> wrote:
>
>>
>>
>>> Hello all,
>>>
>>> Could somebody include these trivial fixes into reSIProcate sources?
>>>
>>>
>>> 1. Multiple "warning C4996: 'strdup': The POSIX name for this item
>>>
> is
>
>>> deprecated. Instead, use the ISO C++ conformant name: _strdup."
>>>
> warnings
>
>>> during ares compilation
>>>
>>> fix: add the following line after windows headers includes under
>>>
> #ifdef
>
>>> WIN32 at the top of contrib/ares.h
>>>
>>> #pragma warning(disable:4996)
>>>
>>>
>>> 2. DialogUsageManager.cxx: "warning C4150: deletion of pointer to
>>> incomplete type 'resip::RemoteCertStore'; no destructor called"
>>>
>>> fix: add the following line into dum/DialogUsageManager.cxx
>>>
>>> #include "resip/dum/RemoteCertStore.hxx"
>>>
>>> --
>>> ...Bye..Dmitry.
>>> _______________________________________________
>>> resiprocate-devel mailing list
>>> resiprocate-devel@xxxxxxxxxxxxxxx
>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>
>>>
>>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel@xxxxxxxxxxxxxxx
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
>>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
>
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel