C strcpy() - 邪恶？

Question

有些人似乎认为 C 的 strcpy() 函数是坏的或邪恶的。 虽然我承认通常最好使用 strncpy() 来避免缓冲区溢出，但以下内容（对于那些不够幸运的人来说是 strdup() 函数的实现）拥有它）安全地使用 strcpy() 并且永远不会溢出：

char *strdup(const char *s1)
{
  char *s2 = malloc(strlen(s1)+1);
  if(s2 == NULL)
  {
    return NULL;
  }
  strcpy(s2, s1);
  return s2;
}

*s2 保证有足够的空间来存储 *s1< /code>，并且使用 strcpy() 使我们不必将 strlen() 结果存储在另一个函数中，以便稍后用作不必要的（在本例中）长度参数到strncpy()。 然而，有些人用 strncpy() 甚至 memcpy() 编写这个函数，它们都需要长度参数。 我想知道人们对此有何看法。 如果您认为 strcpy() 在某些情况下是安全的，请说出来。 如果您有充分的理由在这种情况下不使用 strcpy()，请给出 - 我想知道为什么使用 strncpy() 可能会更好或在这种情况下使用 memcpy() 。 如果您认为 strcpy() 可以，但不在这里，请解释一下。

基本上，我只是想知道为什么有些人使用 memcpy()，而另一些人使用 strcpy()，而还有一些人使用普通的 strncpy()。 是否有任何逻辑比三个更喜欢一个（忽略前两个的缓冲区检查）？

Answer 1

我同意。 不过，我建议不要使用 strncpy() ，因为它总是会将您的输出填充到指定的长度。 这是一个历史性的决定，我认为这确实很不幸，因为它严重恶化了性能。

考虑这样的代码：

char buf[128];
strncpy(buf, "foo", sizeof buf);

这不会将预期的四个字符写入 buf，而是写入“foo”，后跟 125 个零字符。 例如，如果您收集大量短字符串，这将意味着您的实际性能远远低于预期。

如果可用，我更喜欢使用 snprintf()，将上面的内容写成：

snprintf(buf, sizeof buf, "foo");

如果复制非常量字符串，则按如下方式完成：

snprintf(buf, sizeof buf, "%s", input);

这很重要，因为 if input 包含 % 字符 snprintf() 会解释它们，打开一整架的蠕虫罐头。

Answer 2

我认为 strncpy 也很邪恶。

为了真正保护自己免受此类编程错误的影响，您需要避免编写出 (a) 看起来不错和 (b) 超出缓冲区的代码。

这意味着您需要一个真正的字符串抽象，它不透明地存储缓冲区和容量，将它们永远绑定在一起，并检查边界。 否则，您最终会将字符串及其容量传递到整个商店。 一旦您进行了真正的字符串操作，例如修改字符串的中间部分，将错误的长度传递到 strncpy （尤其是 strncat）几乎与使用太小的目标调用 strcpy 一样容易。

当然，您可能仍然会问是使用 strncpy 还是 strcpy 来实现该抽象：只要您完全理解它的作用，strncpy 就更安全。 但在字符串处理应用程序代码中，依靠 strncpy 来防止缓冲区溢出就像戴了半个避孕套。

所以，你的 strdup-replacement 可能看起来像这样（定义的顺序改变了，让你保持悬念）：

string *string_dup(const string *s1) {
    string *s2 = string_alloc(string_len(s1));
    if (s2 != NULL) {
        string_set(s2,s1);
    }
    return s2;
}

static inline size_t string_len(const string *s) {
    return strlen(s->data);
}

static inline void string_set(string *dest, const string *src) {
    // potential (but unlikely) performance issue: strncpy 0-fills dest,
    // even if the src is very short. We may wish to optimise
    // by switching to memcpy later. But strncpy is better here than
    // strcpy, because it means we can use string_set even when
    // the length of src is unknown.
    strncpy(dest->data, src->data, dest->capacity);
}

string *string_alloc(size_t maxlen) {
    if (maxlen > SIZE_MAX - sizeof(string) - 1) return NULL;
    string *self = malloc(sizeof(string) + maxlen + 1);
    if (self != NULL) {
        // empty string
        self->data[0] = '\0';
        // strncpy doesn't NUL-terminate if it prevents overflow, 
        // so exclude the NUL-terminator from the capacity, set it now,
        // and it can never be overwritten.
        self->capacity = maxlen;
        self->data[maxlen] = '\0';
    }
    return self;
}

typedef struct string {
    size_t capacity;
    char data[0];
} string;

这些字符串抽象的问题是，没有人能就其中一个达成一致（例如，上面评论中提到的 strncpy 的特性是否好或好）不好，您是否需要在创建子字符串时共享缓冲区的不可变和/或写时复制字符串等）。 因此，虽然理论上您应该只从货架上拿一个，但最终每个项目都可以拥有一个。

Answer 3

如果我已经计算了长度，我倾向于使用 memcpy ，尽管 strcpy 通常针对机器字进行了优化，但感觉您应该为库提供 as尽可能多的信息，这样它就可以使用最优化的复制机制。

但对于你给出的例子来说，这并不重要 - 如果它会失败，它将在最初的 strlen 中，所以 strncpy 不会给你带来任何安全方面的东西（并且大概< code>strncpy 速度较慢，因为它必须检查边界和 nul），并且 memcpy 和 strcpy 之间的任何差异都不值得推测性地更改代码。

Answer 4

当人们这样使用它时，邪恶就来了（尽管下面是超级简化的）：

void BadFunction(char *input)
{
    char buffer[1024]; //surely this will **always** be enough

    strcpy(buffer, input);

    ...
}

这是一种经常发生的令人惊讶的情况。

但是，是的，在为目标缓冲区分配内存并且已经使用 strlen 来查找长度的任何情况下，strcpy 与 strncpy 一样好。

Answer 5

strlen 找到最后一个空终止位置。

但实际上缓冲区并不是以空值终止的。

这就是人们使用不同功能的原因。

Answer 6

好吧，strcpy() 并不像 strdup() 那么邪恶——至少 strcpy() 是标准 C 的一部分。

Answer 7

在您描述的情况下，strcpy 是一个不错的选择。 仅当 s1 不以“\0”结尾时，此 strdup 才会遇到麻烦。

我会添加一条评论，说明为什么 strcpy 没有问题，以防止其他人（以及一年后的您自己）长时间怀疑它的正确性。

strncpy 通常看起来很安全，但可能会给您带来麻烦。 如果源“字符串”短于 count，它将用 '\0' 填充目标，直到达到 count。 这可能对性能不利。 如果源字符串长于 count，strncpy 不会将 '\0' 附加到目标字符串。 当您稍后期望以“\0”结尾的“字符串”时，这肯定会给您带来麻烦。 所以strncpy也要谨慎使用！

如果我不使用以 '\0' 结尾的字符串，我只会使用 memcpy，但这似乎是一个品味问题。

Answer 8

char *strdup(const char *s1)
{
  char *s2 = malloc(strlen(s1)+1);
  if(s2 == NULL)
  {
    return NULL;
  }
  strcpy(s2, s1);
  return s2;
}

问题：

1. s1未终止，strlen导致访问未分配的内存，程序崩溃。
2. s1 未终止，strlen 同时不会导致从应用程序的其他部分访问未分配的内存访问内存。 它返回给用户（安全问题）或由程序的另一部分解析（出现heisenbug）。
3. s1 未终止，strlen 导致系统无法满足的 malloc，返回 NULL。 strcpy 传递 NULL，程序崩溃。
4. s1 未终止，strlen 导致 malloc 非常大，系统分配太多内存来执行手头的任务，变得不稳定。
5. 在最好的情况下，代码效率很低，strlen 需要访问字符串中的每个元素。

可能还有其他问题...看，空终止并不总是一个坏主意。 在某些情况下，为了计算效率或减少存储需求，这是有意义的。

对于编写通用代码（例如业务逻辑）有意义吗？ 不。

Answer 9

char* dupstr(char* str)
{
   int full_len; // includes null terminator
   char* ret;
   char* s = str;

#ifdef _DEBUG
   if (! str)
      toss("arg 1 null", __WHENCE__);
#endif

   full_len = strlen(s) + 1;
   if (! (ret = (char*) malloc(full_len)))
      toss("out of memory", __WHENCE__);
   memcpy(ret, s, full_len); // already know len, so strcpy() would be slower

   return ret;
}

Answer 10

此答案使用 size_t 和 memcpy() 来实现快速而简单的 strdup()。

最好使用 size_t 类型，因为它是从 strlen() 返回并由 malloc() 和 memcpy()< 使用的类型/代码>。 int 不是这些操作的正确类型。

memcpy() 很少比 strcpy() 或 strncpy() 慢，而且通常要快得多。

// Assumption: `s1` points to a C string.
char *strdup(const char *s1) {
  size_t size = strlen(s1) + 1;
  char *s2 = malloc(size);
  if(s2 != NULL) {
    memcpy(s2, s1, size);
  }
  return s2;
} 

§7.1.1 1 “字符串是由第一个空字符终止并包含第一个空字符的连续字符序列。...”

Answer 11

您的代码效率非常低，因为它运行两次字符串来复制它。

一旦进入 strlen()。

然后再次在 strcpy() 中。

并且您不会检查 s1 是否为 NULL。

将长度存储在一些额外的变量中几乎不需要花费任何成本，而运行每个字符串两次来复制它是一个大罪。

Answer 12

memcpy 可以比 strcpy 和 strncpy 更快，因为它不必将每个复制的字节与 '\0' 进行比较，并且因为它已经知道复制对象的长度。 它可以通过 Duff 的设备以类似的方式实现，或者使用复制的汇编指令一次几个字节，如 movsw 和 movsd

Answer 13

我遵循此处中的规则。 让我引用一下

strncpy 最初被引入 C 库中，用于处理目录条目等结构中的固定长度名称字段。 此类字段的使用方式与字符串不同：对于最大长度字段，不需要尾随 null，并且将较短名称的尾随字节设置为 null 可确保高效的字段明智比较。 strncpy 本质上并不是“有限制的 strcpy”，委员会更愿意承认现有的做法，而不是改变该函数以更好地适应这种用途。

因此，如果您按 n 未找到 '\0'，则不会在字符串中获得尾随 '\0'从源字符串到目前为止。 它很容易被误用（当然，如果你知道这个陷阱，你就可以避免它）。 正如引文所说，它并不是被设计为有界的 strcpy。 如果没有必要，我宁愿不使用它。 就您而言，显然没有必要使用它，并且您证明了这一点。 那为什么要用它呢？

一般来说，编程代码也是为了减少冗余。 如果您知道有一个包含“n”个字符的字符串，为什么要告诉复制函数复制最多 n 个字符？ 你做了多余的检查。 这与性能无关，而更多地与代码的一致性有关。 读者会问自己，strcpy 会做什么，可能会跨越 n 个字符，从而有必要限制复制，只是在手册中读到这不会发生。 在这种情况下。 代码的读者之间开始产生困惑。

为了合理使用 mem-、str- 或 strn-，我在上面的链接文档中选择了它们：

mem - 当我想复制原始字节时，例如结构的字节。

str- 复制空终止字符串时 - 仅当 100% 不会发生溢出时。

strn- 当将空终止字符串复制到一定长度时，用零填充剩余字节。 在大多数情况下可能不是我想要的。 人们很容易忘记尾随零填充的事实，但正如上面引用所解释的那样，这是设计使然。 因此，我只需编写自己的小循环来复制字符，添加尾随 '\0'：

char * sstrcpy(char *dst, char const *src, size_t n) {
    char *ret = dst;
    while(n-- > 0) {
        if((*dst++ = *src++) == '\0')
            return ret;
    }
    *dst++ = '\0';
    return ret;
}

只需几行即可完全满足我的要求。 如果我想要“原始速度”，我仍然可以寻找一个可移植且优化的实现来完成这个有界 strcpy 工作。 一如既往，先分析，然后再进行处理。

后来，C 获得了处理宽字符的函数，称为 wcs- 和 wcsn-（针对 C99）。 我也会同样使用它们。

Answer 14

人们使用 strncpy 而不是 strcpy 的原因是因为字符串并不总是以 null 结尾，并且很容易溢出缓冲区（使用 strcpy 为字符串分配的空间）并覆盖一些不相关的内存位。

对于 strcpy，这种情况可能发生，对于 strncpy，这种情况永远不会发生。 这就是为什么 strcpy 被认为是不安全的。 邪恶可能有点强。

Answer 15

坦率地说，如果您在 C 中进行大量字符串处理，您不应该问自己是否应该使用 strcpy 或 strncpy 或 memcpy。 您应该找到或编写一个提供更高级别抽象的字符串库。 例如，它可以跟踪每个字符串的长度，为您分配内存，并提供您需要的所有字符串操作。

这几乎肯定可以保证您很少犯通常与 C 字符串处理相关的错误，例如缓冲区溢出、忘记以 NUL 字节终止字符串等等。

该库可能具有如下功能：

typedef struct MyString MyString;
MyString *mystring_new(const char *c_str);
MyString *mystring_new_from_buffer(const void *p, size_t len);
void mystring_free(MyString *s);
size_t mystring_len(MyString *s);
int mystring_char_at(MyString *s, size_t offset);
MyString *mystring_cat(MyString *s1, ...); /* NULL terminated list */
MyString *mystring_copy_substring(MyString *s, size_t start, size_t max_chars);
MyString *mystring_find(MyString *s, MyString *pattern);
size_t mystring_find_char(MyString *s, int c);
void mystring_copy_out(void *output, MyString *s, size_t max_chars);
int mystring_write_to_fd(int fd, MyString *s);
int mystring_write_to_file(FILE *f, MyString *s);

我为 Kannel 项目编写了一个函数，请参阅 gwlib/octstr.h 文件。 它使我们的生活变得更加简单。 另一方面，这样的库编写起来相当简单，因此您可以自己编写一个库，即使只是作为练习。

Answer 16

没有人提到strlcpy，由 Todd C. Miller 和 Theo de Raadt 开发。 正如他们在论文中所说：

最常见的误解是
strncpy() NUL 终止
目标字符串。 这只是事实，
但是，如果源的长度
字符串小于大小
范围。 这可能会有问题
复制用户输入时可能是
任意长度变为固定大小
缓冲。 最安全的使用方式
strncpy() 在这种情况下是通过
它比
目标字符串，然后终止
用手拉绳子。 这样你就是
保证总是有一个
以 NUL 结尾的目标字符串。

对于使用 strlcpy 有一些反对意见； 维基百科页面指出

Drepper 认为 strlcpy 和
strlcat 使截断错误更容易
让程序员忽略，从而
可能会引入比它们更多的错误
删除。*

但是，我相信这除了手动调整 strncpy 的参数之外，只是迫使那些知道自己在做什么的人添加手动 NULL 终止。 使用 strlcpy 可以更轻松地避免缓冲区溢出，因为您未能以 NULL 终止缓冲区。

另请注意，glibc 或 Microsoft 的库中缺少 strlcpy 不应成为使用障碍； 您可以在任何 BSD 发行版中找到 strlcpy 及其朋友的源代码，并且该许可证可能对您的商业/非商业项目友好。 请参阅 strlcpy.c 顶部的注释。

Answer 17

我个人的想法是，如果代码能够被证明是有效的并且如此迅速地完成，那么它是完全可以接受的。 也就是说，如果代码很简单并且显然是正确的，那么就可以了。

但是，您的假设似乎是，当您的函数正在执行时，没有其他线程会修改 s1 指向的字符串。 如果此函数在成功内存分配（以及对 strlen 的调用）后被中断，字符串增长，并且 bam 自 以来出现缓冲区溢出情况，会发生什么情况strcpy 复制到 NULL 字节。

下面的情况可能会更好：

char *
strdup(const char *s1) {
  int s1_len = strlen(s1);
  char *s2 = malloc(s1_len+1);
  if(s2 == NULL) {
    return NULL;
  }

  strncpy(s2, s1, s1_len);
  return s2;
}

现在，绳子可以因您自己的错误而增长，并且您很安全。 结果不会是重复，但也不会是任何疯狂的溢出。

您提供的代码实际上成为错误的可能性非常低（如果您在不支持线程的环境中工作，则几乎不存在，甚至不存在） 。 这只是需要思考的事情。

预计到达时间：这是一个稍微好一点的实现：

char *
strdup(const char *s1, int *retnum) {
  int s1_len = strlen(s1);
  char *s2 = malloc(s1_len+1);
  if(s2 == NULL) {
    return NULL;
  }

  strncpy(s2, s1, s1_len);
  retnum = s1_len;
  return s2;
}

返回字符数。 您还可以：

char *
strdup(const char *s1) {
  int s1_len = strlen(s1);
  char *s2 = malloc(s1_len+1);
  if(s2 == NULL) {
    return NULL;
  }

  strncpy(s2, s1, s1_len);
  s2[s1_len+1] = '\0';
  return s2;
}

这将以 NUL 字节终止它。 无论哪种方式都比我最初快速组合的方式要好。