[reSIProcate] Visual Studio 2005 compilation warnings of 1.4 branch

[Robert Sparks]

(This ended up wedged in an admin queue for longer than it should have  
- the lag was not Jason's)

On Dec 9, 2008, at 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
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel