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

[Matthias Moetje <moetje@xxxxxxxxxxxx>]

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 ]"