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