[reSIProcate] Visual Studio 2005 compilation warnings of 1.4 branch

[Jason Fischl]

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