1

I am currently writing a program where i was stuck in a different kind of behaviour of strcpy() function . Here is short demo of it...

I went through the following question : Strip first and last character from C string

//This program checks whether strcpy() is needed or not after doing the modification in the string 
#include <stdio.h>
#include <string.h>

int main()
{
        char mystr[] = "Nmy stringP";
        char *p = mystr ;
        p++;

        p[strlen(p)-1] = '\0';
        strcpy(mystr,p);
        printf("p : %s mystr: %s\n",p,mystr);

}

Output :-

p : y strnng mystr: my strnng

If i dont use strcpy() function , then i get 

p : my string mystr : Nmy string

Why is this happening ??

Community
  • 1
  • 1
Subbu
  • 2,063
  • 4
  • 29
  • 42
  • I don't think you can use `strcpy` with overlapping source and destination. – chris Apr 08 '13 at 04:33
  • 1
    You can't overlap memory for `strcpy()` source and target buffers. The behavior is undefined if you do so. See [the documentation](http://en.cppreference.com/w/c/string/byte/strcpy). – WhozCraig Apr 08 '13 at 04:35
  • 2
    general tip before you get in any deeper: never ever use strcpy. it's been the source of far too much bad code and far too many system vulnerabilities. `strncpy` is preferrable. – Marc B Apr 08 '13 at 04:35
  • `memcpy()` is even more preferable, `memmove()` or overlaps. Either forces you to do what you end up always doing with `strncpy()` anyway: namely hard-terminate the destination buffer. `srtncpy()` is fine (I use it regularly), but knowing how it works (i.e. it *always* writes exactly `n` chars, and no more) is important. – WhozCraig Apr 08 '13 at 04:36
  • @MarcB: strcpy isn't the source of system vulnerabilities; Poor system design is the source of system vulnerabilities... and `strncpy` isn't excluded from poor system design. Using `strncpy` can introduce a new class of vulnerabilities: Information disclosure due to lack of `'\0'` termination. Using strcpy in algorithms that are designed well isn't problematic at all. – autistic Apr 08 '13 at 04:40
  • @modifiablelvalue: at least with strncpy, you don't have to HOPE for a null terminator. you might still trash something, but only up to `n` bytes worth, rather than the 0->MAX_INT range possible with strcpy – Marc B Apr 08 '13 at 04:44
  • @MarcB strncpy doesn't necessarily produce strings, which is where the problem with your advice lies. Don't convince people that it does. You can't give a definition to undefined behaviour. – autistic Apr 08 '13 at 04:54
  • Sir , as per documentation , `strncpy` still gives undefined behaviour when overlapping objects , hence this would also not solve the issue...i think .. – Subbu Apr 08 '13 at 11:52
  • @Marc: strncpy is in no way preferable. strncpy is a death trap. If there is not enough space, it will produce a result that isn't a valid string. When copying UTF-8 strings, which is a huge percentage of the use cases for large strings, it can produce invalid results. There is strlcpy, but the best way is to have code that just allocates enough memory for the result. – gnasher729 Jun 03 '14 at 16:39

2 Answers2

9

The standard says:

7.24.2.3

If copying takes place between objects that overlap, the behavior is undefined.

You could use memmove or a different method altogether.

cnicutar
  • 178,505
  • 25
  • 365
  • 392
1

You can not use strcpy with overlapping memory locations i.e., if source and destination strings overlap. In this case, the behavior is undefined as stated in the standards.

But you can use a temp memory location to do the swap like this

Abhineet
  • 5,320
  • 1
  • 25
  • 43