reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] Visual Studio 2005 compilation warnings of 1.4 branch

(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@xxxxxxxxxxxx
GERMANY             Web:    www.terasens.com
______________________________________________




-----Original Message-----
From: Adam Roach [mailto:adam@xxxxxxxxxxx]
Sent: Sonntag, 7. Dezember 2008 19:48
To: Matthias Moetje
Cc: Max Bowsher; resiprocate-devel@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel


_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel