Strlcpy

From Wikipedia, the free encyclopedia

The correct title of this article is strlcpy. The initial letter is shown capitalized due to technical restrictions.

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. A string (of non-zero length) copied by strlcpy is always nul-terminated, making it simpler to locate the end of the string. The function takes the size of the destination as a parameter, making buffer overflows less likely. 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.

1 Controversy
2 Security concerns
3 References
4 External links

[edit] Controversy

The strlcpy and strlcat functions are controversial.^[1]^[2] They are commonly used to replace calls to strcpy and strcat, but no study has demonstrated that this approach leads to safer or more-secure software than standard C functions like memcpy. Some argue that use of strlcpy and strlcat makes C code harder to read and maintain,^{[citation needed]} although this is highly subjective, and others have noted implementation differences between the BSD and Solaris implementations^[3]. Furthermore, some, including Ulrich Drepper, argue that use of strlcpy and strlcat can introduce more bugs than they remove^[2]; consequently, these functions have not been added to the GNU C Library. Drepper endorses the use of the mempcpy function rather than strlcpy, although this function differs from strlcpy in that, as with memcpy, it complicates the use of standard C strings (the programmer must know or ascertain the string length separately rather than the function making use of a null terminator). Also, mempcpy itself cannot be used to detect truncation, although since its use requires the programmer to know the destination buffer length, and the source string length may usually be ascertained, this can by and large be tested for, albeit in a more verbose fashion than with strlcpy. An example of mempcpy usage is:

       *((char *) mempcpy(dst, src, n)) = '\0';

[edit] Security concerns

While strlcpy is a clear improvement over strcpy, the case is not so clear when compared to strncpy. strlcpy requires that the source string be properly null-terminated. When this condition is violated, strlcpy can leak information after the original source string into the destination buffer.