1

I would like to know if there is a difference between char* test = "test" and strcpy(test, "test"), and if there is one, what is this difference.

Thanks.

iAmoric
  • 1,787
  • 3
  • 31
  • 64

1 Answers1

1

The strcpy function (which you should never use! -- use strncpy or strdup to avoid buffer overflow vulnerabilities), copies the bytes from one string buffer to the other; assignment changes the buffer to which you are pointing. Note that to invoke strncpy (or strcpy, but don't!) you need to have a buffer already allocated to do this copy. When you do an assignment from a literal string, the compiler has effectively created a read-only buffer, and your pointer is updated with the address of that.

UPDATE

As pointed out in the comments, strncpy has its drawbacks, too. You are much better off using your own helper functions to copy the data from one buffer to another. For example:

ReturnCode CopyString(char* src, char* out, int outlen) {
   if (!src) {
     return NULL_INPUT;
   }
   if (!out) {
     return NULL_OUTPUT;
   }
   int out_index = 0;
   while ((*src != '\0') && (out_index < outlen - 1)) {
     out[out_index++] = *src;
     src++;
   }
   out[out_index] = '\0';
   if (*src != '\0') {
      if (outlen > 0) {
         out[0] = '\0';  // on failure, copy empty rather than partially
      }
      return BUFFER_EXCEEDED;
   }
   return COPY_SUCCESSFUL;
}

And, if you can use C++, not just C, then I would suggest using std::string.

Michael Aaron Safyan
  • 93,612
  • 16
  • 138
  • 200
  • 5
    strcpy is perfectly fine for what it does. There is no sign of plans to deprecate it in the standard. strncpy is *very* easy to use incorrectly. A simple "use strncpy" with no examples of correct *and incorrect* usage is not going to help. `strdup` is non-standard. – n. m. could be an AI Dec 11 '16 at 09:12
  • @strcpy I never said that strcpy is deprecated (unfortunately, deprecating anything in the POSIX standard would be thoroughly impractical); however, strcpy is not okay for what it does; strcpy does not know the size of the destination buffer to which it is writing, so if the destination buffer is not large enough, it will overwrite other memory. As for strdup, it actually is standard (albeit not the C standard); it is a part of the Single UNIX Specification. It's main drawback is that it results in an additional allocation rather than reusing an existing buffer like strncpy. – Michael Aaron Safyan Dec 11 '16 at 09:16
  • 2
    `strcpy` is safer than `strncpy` because it never generates a non-null-terminated string – M.M Dec 11 '16 at 09:19
  • @M.M fair point. Both are pretty unsafe, though I would argue that strcpy is the more unsafe of the two, because you can make strncpy safe by additionally assigning a NUL terminator; you cannot make strcpy safe. – Michael Aaron Safyan Dec 11 '16 at 09:21
  • 5
    You can make `strcpy` safe by calling it only when you know that the string will fit in the buffer – M.M Dec 11 '16 at 09:23
  • 2
    `strcpy` is not unsafe, it is almost always used UNSAFE (wrong). – Michi Dec 11 '16 at 09:27
  • 1
    `gets` was in POSIX and was outright removed, and it was perfectly fine to do so because `gets` *was* unsafe. `strcpy` isn't. "strcpy does not know the size of the destination buffer to which it is writing". A function knows nothing, it's the programmer who makes sure the buffer is large enough. `strncpy` doesn't know anything either. It's the programmer telling it the size. I've seen enough programmers passing in the wrong size, and then going like "hey, but I was told *by the management* to use `strncpy` *because it's safe*!" – n. m. could be an AI Dec 11 '16 at 09:28
  • 1
    @Michi So is `strncpy`. – n. m. could be an AI Dec 11 '16 at 09:34
  • @n.m. Agree. Standard Functions aren't perfect. It is the Programmer problem how he/she use it. – Michi Dec 11 '16 at 09:36