背景：
我有一个模仿fgets(character, 2, fp) 的小例程，除了它从字符串而不是流中获取字符。 newBuff 是动态分配的字符串，作为参数传递，字符声明为char character[2]。
例行公事：
character[0] = newBuff[0];
character[1] = '\0';
strcpy(newBuff, newBuff+1);
strcpy 在读取每个字符时复制信息的丢失。
问题：Valgrind 确实警告过我 这个活动，“来源和目的地 strcpy 中的重叠（0x419b818， 0x419b819)"。
我应该担心这个警告吗？
【问题讨论】：
答案是肯定的：对于某些编译器/库实现，我猜是最新的，你最终会得到一个虚假的结果。示例见How is strcpy implemented?。
【讨论】：
如果源和目标重叠，strcpy() 的行为是官方未定义的。
来自 memcpy 的手册页有一个建议：
memcpy() 函数将 n 个字节从内存区 s2 复制到内存区 s1。如果 s1 和 s2 重叠，则行为未定义。 s1 和 s2 可能重叠的应用程序应该使用 memmove(3) 代替。
【讨论】：
strcpy 如果缓冲区重叠，则会给出未定义的行为。 memcpy 做同样的事情，但在其他方面无关紧要。
memmove 和wmemmove。对于其他所有内容（包括snprintf！），行为未定义。
可能标准没有指定这些缓冲区重叠时会发生什么。所以是的，valgrind 对此进行投诉是对的。
实际上，您很可能会发现您的 strcpy 按从左到右的顺序复制（例如while (*dst++ = *src++);），这不是问题。但它仍然不正确，并且在与其他 C 库一起运行时可能会出现问题。
一种符合标准的写法是：
memmove(newBuff, newBuff+1, strlen(newBuff));
因为memmove 被定义为处理重叠。 （虽然在这里你最终会遍历字符串两次，一次检查长度，一次复制。我也采取了捷径，因为strlen(newBuff) 应该等于strlen(newBuff+1)+1，这是我最初写的。）
【讨论】：
strcpy 的这种用法非常不安全，并且可能在同一库的不同版本之间甚至在使用不同编译器的不同构建之间实现平衡。
是的，您还应该担心您的函数的性能非常糟糕（O(n^2) 表示应该是 O(n) 的任务）。每次读取一个字符时将字符串的全部内容向后移动一个字符是非常浪费时间的。相反，您应该只保留一个指向当前位置的指针并增加该指针。
您发现自己需要memmove 或等效项（在重叠的缓冲区之间复制）的情况几乎总是表明存在设计缺陷。通常这不仅仅是实现中的缺陷，而是界面中的缺陷。
【讨论】：
是的，你应该担心。 C 标准规定，当源对象和目标对象重叠时，strcpy 的行为是undefined。未定义的行为意味着它有时可能会起作用，或者可能会失败，或者它可能看起来成功但在程序的其他地方明显失败。
【讨论】：
是的——strcpy 的行为仅在源和目标不重叠时定义。您可以考虑将strlen 和memmove 组合使用。
【讨论】：