strlcpy

In computer programming, the strlcpy function is intended to replace the function strcpy and provide a simpler and more robust and secure interface than strncpy. It is designed to copy the contents of a string from a source string to a destination string. It is almost always accompanied by the strlcat function which provides a similar alternative to strncat.

They are not C standard library functions, but are common in Berkeley Software Distribution-derived operating systems.

Usage

   size_t strlcpy(char *destination, const char *source, size_t size);
   size_t strlcat(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, avoiding buffer overflows if 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");

strlcat is equivalent to doing strcat into a buffer large enough to hold the result and then doing strlcpy of that buffer to the destination.

History

strlcpy and strlcat were developed by Todd C. Miller and Theo de Raadt and first implemented in 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.

Criticism

Red Hat developers Ulrich Drepper and James Antill are critics of the strlcpy and strlcat functions; consequently these functions have not been added to the GNU C Library. Antill notes that they are non-standard and 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 differs). Antill also expressed concern regarding the risks of truncation when using any string function involving static allocation. Drepper argues that strlcpy and strlcat make truncation errors easier for a programmer to ignore and thus can introduce more bugs than they remove.

External links

• strlcpy and strlcat--Consistent, Safe, String Copy and Concatenation - a paper written by Miller and de Raadt, presented at Usenix 99
• Template:Man
• strlcpy() source
• strlcat() source
• Linux Weekly News discussion of strlcpy
• Developer Blog discussion of strlcpy and mempcpy