Differences between current version and predecessor to the previous major change of strncpy(3).
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 6 | Last edited on Tuesday, May 24, 2005 6:48:42 pm | by HarunVos | |
| Older page: | version 1 | Last edited on Tuesday, June 4, 2002 12:24:36 am | by perry | Revert |
@@ -1,64 +1,52 @@
-STRCPY
!!!STRCPY
-NAME
-SYNOPSIS
-DESCRIPTION
-RETURN VALUE
-BUGS
-CONFORMING TO
-SEE ALSO
----
!!NAME
strcpy, strncpy - copy a string
!!SYNOPSIS
-__
#include
-__''dest''__, const char *__''src''__);
-char *strncpy(char *__''dest''__, const char *__''src''__, size_t__ ''n''__);
-
+
#include <string.h>
+
+ __char *strcpy(
__''dest''__, const char *__''src''__);__
+
+ __
char *strncpy(char *__''dest''__, const char *__''src''__, size_t__ ''n''__);__
+
!!DESCRIPTION
-
The __strcpy()__ function copies the string pointed to by
''src'' (including the terminating `0' character) to the
array pointed to by ''dest''. The strings may not
overlap, and the destination string ''dest'' must be
large enough to receive the copy.
-
The __strncpy()__ function is similar, except that not
more than ''n'' bytes of ''src'' are copied. Thus, if
there is no null byte among the first ''n'' bytes of
''src'', the result wil not be
null-terminated.
-
In the case where the length of ''src'' is less than that
of ''n'', the remainder of ''dest'' will be padded
with nulls.
+
!!RETURN VALUE
-
-
The __strcpy()__ and __strncpy()__ functions return a
pointer to the destination string ''dest''.
+
!!BUGS
-
-
If the destination string of a __strcpy()__ is not large
enough (that is, if the programmer was stupid/lazy, and
failed to check the size before copying) then anything might
happen. Overflowing fixed length strings is a favourite
cracker technique.
+
!!CONFORMING TO
+SVID 3, POSIX, BSD 4.3, ISO 9899
+!!HISTORY
+Rumour has it that the reason that strncpy() has such bizarre semantics (copying up to the entire length of the string and not leaving space for the terminating '0', and padding to the end of the buffer with '0's if it's shorter) come from the days when you could read/write a directory. If you wanted to create a hardlink you opened the directory for writing and wrote the filename and the inode number into the directory. The filename had to be exactly ''n'' bytes long and must be '0' padded (instead of just terminated), hence the strncpy() semantics. It's far too late now to change the semantics to something more sane, so the [OpenBSD] people are advocating the use of strlcpy(3) instead. Note, in high performance applications, strlcpy(3) is much faster than strncpy(3) as it doesn't waste time padding the entire string.
-SVID 3, POSIX, BSD 4.3, ISO 9899
!!SEE ALSO
-
-
-
-
-----
+bcopy(3), memccpy(3), memcpy(3), memmove(3)
