strcpy_s vs strcpy
in [C++]
|
Prev: composition and bad_alloc
Next: ANN: Library dependency graphs tool status update and questions
From: Stephen Howe on 4 Jul 2008 19:02 > Apart from the part it's perfectly useless Microsoft-specific > monstruosity and duplicates the standard strncpy, I do not think there > is any. I hate strncpy() : It does not always '\0 terminate the destination It always writes n characters even if the source string is shorter. I have code-wise been doing strncpy(dest, source, n); dest[n] = '\0'; assuming dest is n + 1 chracters big, but of late I have used strncat dest[0] = '\0'; strncat(dest, source, n); because of strncpy()'s shortcomings. Stephen Howe -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: red floyd on 5 Jul 2008 03:21 { accepting hoping that the discussion will be kept technical. -mod } Greg Herlihy wrote: > On Jul 3, 7:53 am, Thomas Richter <t...(a)math.tu-berlin.de> wrote: >> I wonder why there is a need for an additional interface if there are >> already functions that do that for you? Or to put this in different >> words, what's wrong with strncpy() that makes strcpy_s necessary? > > For one, strncpy() has no parameter specifying the size of the > destination buffer char *strncpy(char *, const char *, size_t); What is that third paramerer, then? -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Greg Herlihy on 5 Jul 2008 20:58 On Jul 5, 11:21 am, red floyd <no.spam.h...(a)example.com> wrote: > { accepting hoping that the discussion will be kept technical. -mod } > > Greg Herlihy wrote: > > For one, strncpy() has no parameter specifying the size of the > > destination buffer > > char *strncpy(char *s1, const char *s2, size_t n); > > What is that third paramerer, then? The third parameter to strncpy() specifies the maximum number of characters that the function is to copy from s2 to s1 - a number which could be larger, smaller or the same - as the number of bytes in the destination buffer. After all, the number of bytes allocated for the destination buffer, s1, is not a function of strncpy()'s third parameter, "n". Therefore, the only way for strncpy() to know the size of the destination buffer is for the caller to provide that information with an additional parameter. Moreover, it is easy enough to demonstrate this non-correlation with some examples of strncpy() calls. Because - if there is some kind of correlation between "n" and the size of the s1 buffer _ then changing the size of the destination buffer should also affect the value of n. For example, calling strncpy() to copy (at most) two characters of a string into a 16-byte buffer should pass a different "n" then a strncpy() call to copy (at most) two characters into a 32-byte buffer. Yet, the value of "n" is the same for both calls: char bufA[16]; bufB[32]; stncpy(bufA, "one", 2); stncpy(bufB, "one", 2); // destination buffer size has changed - // but the value of "n" has not whereas the comparable call to strncpy_s() does show the expected change (in the value of second argument) whenever the size of the destination buffer, s1, changes : strncpy_s(bufA, sizeof(bufA), "one", 2); strncpy_s(bufB, sizeof(bufB), "one", 2); // value of second argument changes Therefore - and exactly as I noted in my previous post - there is no way for a caller to provide (nor anyway for strncpy() to deduce on its own) the size of the destination buffer. Greg -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Pavel Minaev on 5 Jul 2008 21:00 On Jul 5, 10:21 pm, red floyd <no.spam.h...(a)example.com> wrote: > { accepting hoping that the discussion will be kept technical. -mod } > > Greg Herlihy wrote: > > On Jul 3, 7:53 am, Thomas Richter <t...(a)math.tu-berlin.de> wrote: > >> I wonder why there is a need for an additional interface if there are > >> already functions that do that for you? Or to put this in different > >> words, what's wrong with strncpy() that makes strcpy_s necessary? > > > For one, strncpy() has no parameter specifying the size of the > > destination buffer > > char *strncpy(char *, const char *, size_t); > > What is that third paramerer, then? Number of characters to copy, which is not the same. strncpy just copies that many characters from the source string (null-padding if necessarily), but it won't read to the end of the source string to see that there were any more left (and, indeed, to check that the source string is even null-terminated), nor it will report it. In contrast, strcpy_s takes the size of the destination buffer - so it always reads the source string to the end, and, if its length is larger than the size of the buffer, will report it in a well-defined manner (by calling the invalid parameter handler, and, possibly, returning EINVAL from strcpy_s). I admit the difference may seem subtle, but it is there. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Erik Wikström on 6 Jul 2008 07:33
On 2008-07-06 13:58, Greg Herlihy wrote: > On Jul 5, 11:21 am, red floyd <no.spam.h...(a)example.com> wrote: >> { accepting hoping that the discussion will be kept technical. -mod } >> >> Greg Herlihy wrote: >> > For one, strncpy() has no parameter specifying the size of the >> > destination buffer >> >> char *strncpy(char *s1, const char *s2, size_t n); >> >> What is that third paramerer, then? > > The third parameter to strncpy() specifies the maximum number of > characters that the function is to copy from s2 to s1 - a number which > could be larger, smaller or the same - as the number of bytes in the > destination buffer. After all, the number of bytes allocated for the > destination buffer, s1, is not a function of strncpy()'s third > parameter, "n". Therefore, the only way for strncpy() to know the size > of the destination buffer is for the caller to provide that > information with an additional parameter. > > Moreover, it is easy enough to demonstrate this non-correlation with > some examples of strncpy() calls. Because - if there is some kind of > correlation between "n" and the size of the s1 buffer _ then changing > the size of the destination buffer should also affect the value of n. > For example, calling strncpy() to copy (at most) two characters of a > string into a 16-byte buffer should pass a different "n" then a > strncpy() call to copy (at most) two characters into a 32-byte buffer. > Yet, the value of "n" is the same for both calls: > > char bufA[16]; bufB[32]; > > stncpy(bufA, "one", 2); > stncpy(bufB, "one", 2); // destination buffer size has changed - > // but the value of "n" has not > > whereas the comparable call to strncpy_s() does show the expected > change (in the value of second argument) whenever the size of the > destination buffer, s1, changes : > > strncpy_s(bufA, sizeof(bufA), "one", 2); > strncpy_s(bufB, sizeof(bufB), "one", 2); // value of second > argument changes > > Therefore - and exactly as I noted in my previous post - there is no > way for a caller to provide (nor anyway for strncpy() to deduce on its > own) the size of the destination buffer. Of course, this advantage disappears as soon as all you've got is a pointer to the beginning of the buffer and the (alleged) size of the buffer, which is often the case. The real value of the _s functions lies in the additional checks and guarantees they provide. -- Erik Wikström [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |