The C programming language offers a library function called strcpy, defined in the string.h header file, that allows null-terminated memory blocks to be copied from one location to another. Since strings in C are not first-class data types and are implemented instead as contiguous blocks of bytes in memory, strcpy will effectively copy strings given two pointers to blocks of allocated memory.
The prototype of the function is:[1]
char *strcpy(char *destination, const char *source);
The return value is destination.
Contents |
Usage and implementation
For example
char *str1 = "abcdefghijklmnop"; char *str2 = malloc(100); /* must be large enough to hold the string! */ strcpy(str2, str1); /* the argument order mimics that of an assignment: str2 "=" str1 */ str2[0] = 'A'; /* str2 is now "Abcdefghijklmnop" */
In the second line memory is allocated to hold the copy of the string, then the string is copied from one memory block into the other, then the first letter of that copy is modified.
Although the simple assignment str2 = str1 might appear to do the same thing, it only copies the memory address of str1 into str2 but not the actual string. Both str1 and str2 would refer to the same memory block, and the allocated block that used to be pointed to by str2 would be lost. The assignment to str2[0] would either also modify str1, or it would cause an access violation (as modern compilers often place the string constants in read-only memory).
The strcpy function performs a copy by iterating over the individual characters of the string and copying them one by one. An explicit implementation of strcpy is:
char *strcpy(char *dest, const char *src) { unsigned i; for (i=0; src[i] != '\0'; ++i) dest[i] = src[i]; dest[i] = '\0'; return dest; }
A common compact implemenation is:
char *strcpy(char *dest, const char *src) { char *save = dest; while(*dest++ = *src++); return save; }
Modern versions provided by C libraries often copy far more than one byte at a time, relying on bit math to detect if the larger word has a nul byte before writing it. Often a call compiles into an inline machine instruction specifically designed to do strcpy.
Unicode
strcpy will work for all common byte encodings of Unicode strings, including UTF-8. There is no need to actually know the encoding as long as the nul byte is never used by it.
If Unicode is encoded in units larger than a byte, such as UTF-16, then a different function is needed, as nul bytes will occur in parts of the larger code units. C99 defines the function wcscpy(), which will copy wchar_t-sized objects and stop at the first one with a zero value. This is not as useful as it appears as there platforms disagree on how large a wchar_t is, some use 16 bits and some 32 bits.
Buffer overflows
strcpy can be dangerous because if the string to be copied is too long to fit in the destination buffer, it will overwrite adjacent memory, invoking undefined behavior. Usually the program will simply cause a segmentation fault when this occurs, but a skilled attacker can use such a buffer overflow to break into a system (see computer security).
Bounds checking variants
To prevent buffer overflows, several alternatives for strcpy have been used. All of them take an extra argument which is the length of the destination buffer and will not write past that buffer end. All of them can still result in buffer overflows if an incorrect length is provided.
strncpy
The most common bounded variant, strncpy, writes exactly the given number of bytes, either only copying the start of the string if it is too long, or adding zeros to the end of the copy to fill the buffer. Because it does not null terminate the copy when the source string is too long it can sometimes result in a read exception if the program later reads the buffer. It can also waste considerable time writing the trailing null bytes if the string is much smaller than the buffer. An alternative that will always append one null byte would be to instead use strncat with an initially empty string as the destination.
strlcpy
The strlcpy function, created by OpenBSD developers Todd C. Miller and Theo de Raadt, is often regarded as a safer version of strncpy. It always adds a single null byte, and returns the number of bytes that would be needed, allowing the caller to reallocate the buffer if possible. It has been ported to a number of operating systems, but notably rejected by glibc maintainers, who suggest that C programmers need to keep track of string length and that "using this function only leads to other errors."[2]
strcpy_s
The strcpy_s function, proposed for standardisation in ISO/IEC TR 24731,[3][4] is supported by the Microsoft C Runtime Library.[5][6] and some other C libraries. It returns non-zero if the source string does not fit, and sets the buffer to the empty string causing further problems if the caller ignores the return result. It is also explicitly unsupported by some libraries, including the GLibc library.[7] Warning messages produced by Microsoft's compilers suggesting programmers change strcpy and strncpy to this function have been speculated by some to be a Microsoft attempt to lock developers to its platform.[8][9]
References
- ^ strcpy - C++ Reference
- ^ libc-alpha mailing list, selected messages from 8 Aug 2000 thread: 53, 60, 61
- ^ ISO/IEC. ISO/IEC WDTR 24731 Specification for Secure C Library Functions. International Organization for Standardization. http://www.open-std.org/jtc1/sc22/wg14/www/projects#24731. Retrieved 2008-04-23.
- ^ Plakosh, Daniel. "strcpy_s() and strcat_s()". Pearson Education, Inc.. https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/coding/314.html. Retrieved 2006-08-12.
- ^ Microsoft. "Security Enhancements in the CRT". MSDN. http://msdn2.microsoft.com/en-us/library/8ef0s5kh(d=ide).aspx. Retrieved 2006-08-12.
- ^ Microsoft. "Security Enhancements in the CRT". MSDN. http://msdn.microsoft.com/en-us/library/8ef0s5kh.aspx. Retrieved 2008-09-16.
- ^ "Re: Implementing "Extensions to the C Library" (ISO/IEC WG14 N1172)". http://sources.redhat.com/ml/libc-alpha/2007-09/msg00069.html.
- ^ Danny Kalev. "They're at it again". InformIT. http://www.informit.com/blogs/blog.aspx?uk=Theyre-at-it-again.
- ^ "Security Enhanced CRT, Safer Than Standard Library?". http://fsfoundry.org/codefreak/2008/09/15/security-crt-safer-than-standard-library/.
External links
This entry is from Wikipedia, the leading user-contributed encyclopedia. It may not have been reviewed by professional editors (see full disclaimer)




