Strlcpy

The strlcpy function, developed by Todd C. Miller and Theo de Raadt for use in the C programming language, is intended to replace the function strcpy and provide a simpler and more robust interface than strncpy. It is designed to copy the contents of a string from a source string to a destination string.

size_t strlcpy(char *destination, const char *source, size_t size);

strlcpy offers two features that are designed to help software developers avoid problems. The function takes the size of the destination as a parameter, making buffer overflows impossible (provided the size parameter is correct). If this size is greater than zero, a nul byte is always written to the destination, so the resulting string is always nul-terminated (even if the source string was truncated to fit). For performance reasons, strlcpy does not fill any unused space in a destination string with zeros, unlike strncpy. Additionally, strlcpy returns the length of the source string, which can be compared to size to check for truncation, for example:

if (strlcpy(dest, source, dest_len) >= dest_len) errx(1, "String too long");

strlcpy was first introduced with OpenBSD version 2.4. It has subsequently been adopted by a number of operating systems including FreeBSD (from version 3.3), Solaris and Mac OS X. Many application packages and libraries include their own copies of these functions, including glib, rsync and the Linux kernel itself.

Similarly, there is a variant of strcat, called strlcat.

Controversy

The strlcpy and strlcat functions are controversial. [ [http://www.gatago.com/comp/unix/programmer/8301563.html strlcpy missing on Linux ] ] [http://sources.redhat.com/ml/libc-alpha/ libc-alpha mailing list] , selected messages from 8 August 2000 thread: [http://sources.redhat.com/ml/libc-alpha/2000-08/msg00053.html 53] , [http://sources.redhat.com/ml/libc-alpha/2000-08/msg00060.html 60] , [http://sources.redhat.com/ml/libc-alpha/2000-08/msg00061.html 61] ] It has been noted that they are non-standard, that there are implementation differences between the BSD and Solaris implementations (the return value of strlcat when there is no nul in the destination buffer), [Antill, James. [http://www.and.org/vstr/security#libcstring Security with string APIs] ] and that no study has demonstrated that they lead to safer or more-secure software than using standard C functions.Fact|date=March 2007 Furthermore, some, including Ulrich Drepper, argue that strlcpy and strlcat make truncation errors easier for a programmer to ignore and thus can introduce more bugs than they remove; consequently, these functions have not been added to the GNU C Library. Others have expressed concern regarding the risks of truncation when using any string function involving static allocation. [Antill, James. [http://www.and.org/vstr/security#alloc Security with string APIs: Security relevant things to look for in a string library API] ]

References

External links

* [http://www.usenix.org/events/usenix99/millert.html strlcpy and strlcat--Consistent, Safe, String Copy and Concatenation] - a paper written by Miller and de Raadt, presented at Usenix 99
*
* [http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/strlcpy.c?rev=1.11&content-type=text/x-cvsweb-markup strlcpy() source]
* [http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/strlcat.c?rev=1.13&content-type=text/x-cvsweb-markup strlcat() source]
* [http://lwn.net/Articles/33812/ Linux Weekly News discussion of strlcpy]
* [http://undeadly.org/cgi?action=article&sid=20060405212010&mode=flat Developer Blog discussion of strlcpy and mempcpy]