[reSIProcate] Visual Studio 2005 compilation warnings of 1.4 branch

[Adam Roach]

Ares.

/a

On 12/9/08 5:31 PM, Jason Fischl wrote:
> Where are we using strcpy where Data couldn't be used? I seem to 
> recall that there were almost no uses of the unsafe c library 
> functions in resip.
>
> Jason
>
>
> On Dec 9, 2008, at 3:13 PM, Matthias Moetje wrote:
>
>> Adam,
>>
>> thanks for the explanations. A more detailed technical discussion 
>> about strncpy and strcpy_s can be found here:
>>
>> http://objectmix.com/c/706786-strcpy_s-vs-strcpy-2.html
>>
>> I would vote to move to the *_s functions and create wrappers for 
>> non-Win-platforms that are semantically identical, like for example:
>>
>>
>> errno_t strcpy_s(char *strDestination, size_t sizeInBytes, const char 
>> *strSource)
>> {
>>     // Parameter check
>>     if ((strDestination == NULL) || (strSource == NULL))
>>     {
>>         return EINVAL;
>>     }
>>     if (sizeInBytes == 0)
>>     {
>>         return ERANGE;
>>     }
>>     
>>     // Measure source string but only as long as it is
>>     // not larger than the destination buffer
>>     size_t srcLen = strnlen(strSource, sizeInBytes);
>>
>>     if (srcLen >= sizeInBytes) // '>' should never be the case
>>     {
>>         // Source string is larger than dest buffer
>>         // Overrun detected. Do not modify strDestination
>>         return ERANGE;
>>     }
>>     
>>     //
>>     strncpy(strDestination, strSource, srcLen);   
>> }
>>
>> Although this wrapper might seem a bit more complex, it can even improve
>> performance (compared to strncpy alone) when copying small strings to
>> large buffers, since strnlen stops when it finds the null terminator
>> and in this case the result of strnlen is used to limit copying with
>> strncpy. When using strncpy alone, it would pad the whole dest buffer
>> with zeros.
>>
>>
>> An advantage with this approach is that this will stronger force
>> us to check the result of the *_s functions in the code and take
>> appropriate measures which is not the case with the strn* functions.
>>
>>
>> Best regards,
>> Freundliche Grüße,
>>
>> Matthias Moetje
>> ______________________________________________
>>
>> TERASENS GmbH       Phone:  +49.89.143370-0
>> Augustenstraße 24   Fax:    +49.89.143370-22
>> 80333 Munich        e-mail: info at terasens.com
>> GERMANY             Web:    www.terasens.com
>> ______________________________________________
>>
>>
>>
>>> -----Original Message-----
>>> From: Adam Roach [mailto:adam at nostrum.com]
>>> Sent: Sonntag, 7. Dezember 2008 19:48
>>> To: Matthias Moetje
>>> Cc: Max Bowsher; resiprocate-devel at resiprocate.org
>>> Subject: Re: [reSIProcate] Visual Studio 2005 compilation warnings 
>>> of 1.4
>>> branch
>>>
>>> Matthias Moetje wrote:
>>>> The safe string functions are in fact not underscore-prefixed; at
>>>> least those not starting with 'str'. Instead they are suffixed
>>>> with '_s' which isn't really that bad. Apart from prefixes and 
>>>> suffixes
>>>> in the end there is no doubt that these functions really improve code
>>>> quality and security.
>>>>
>>>> I hope to be able to start with the function replacement in Jan
>>>> Or Feb 2009 if there are no objections.
>>>>
>>>
>>> Don't.
>>>
>>> Here's what's going on with the *_s functions. Microsoft submitted a
>>> batch of "more secure" functions (such as strcpy_s) to the ISO/IEC for
>>> potential inclusion in a future version of the C standard (the draft
>>> that defines these proposed functions is here:
>>> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1135.pdf). As far as I
>>> can tell, they have not been accepted for future inclusion yet, and
>>> there is significant push-back in the developer community against this
>>> set of functions
>>> (<http://sources.redhat.com/ml/libc-alpha/2007-09/msg00069.html>,
>>> <http://www.informit.com/blogs/blog.aspx?uk=Theyre-at-it-again>,
>>> <http://fsfoundry.org/codefreak/2008/09/15/security-crt-safer-than-standard- 
>>>
>>> library/>).
>>>
>>> In any case, these functions do not appear to have been implemented
>>> under OS X Leopard; nor is it in any of the libc versions that I can
>>> find installed by default with Ubuntu or Fedora (both glibc; see the
>>> first link in my list above). I suspect these functions have not been
>>> widely implemented outside of Redmond.
>>>
>>> For most of the string functions, you can accomplish the same security
>>> properties with C89/C99 functions like strncpy, as long as you are
>>> careful to null-terminate your destination buffer when you're done.
>>>
>>> So, if you wanted to go through and fix things to use the C89 "safer"
>>> functions (like strncpy), that would be a Good Thing -- but it's
>>> apparently not going to fix the Microsoft compiler warnings. For that,
>>> you'll apparently need to convince Microsoft to stop being so
>>> provincial. Or you can define '"_CRT_SECURE_NO_WARNINGS" in the 
>>> project,
>>> which is probably the best approach under the circumstances.
>>>
>>> /a
>>>
>>> P.S. Digging through this mess, I was pointed to an interesting
>>> development in the draft C++0x standard: "The class template 
>>> auto_ptr is
>>> deprecated. [ Note:The class template unique_ptr (20.6.5) provides a
>>> better solution.
>>> - end note ]"
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at resiprocate.org
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>