c - glibc 中的 strncpy 实现太复杂

Question

我正在尝试理解 string.h 函数。这是我自己实现的 strncpy()

char * my_strncpy(char *dst, const char* src, int n)
{
    char *orig = dst;
    const char *hold = src;
    int count = 0, remain = 0;
    while(*(hold++))
            count++;
    if ( n > count )
    {
            remain = n - count;
            n = count;
    }
    while(n--)
            *dst++ = *src++;
    while(remain--)
            *dst++ = '\0';
    return orig;
}

但是在查看 glibc 实现时 here ，我想知道为什么它太大太复杂了。

我使用“time”命令测试了执行时间。这两个功能运行几乎相同。
有人可以分享有关 glibc strncpy() 的知识以及我在 my_strncpy() 中缺少的内容吗？

Answer 1

从现代 C 编程的角度来看，“Glibc”代码写得非常糟糕。它看起来像是针对具有 32 位对齐的特定平台的一系列过早优化。如果编译器是垃圾，那么您将不得不以首选对齐方式为单位对字节进行分组，并一次将它们复制一个这样的单元。这就是代码看起来如此怪异的主要原因。

我猜这些代码很可能是很久以前写的，那时编译器在优化代码方面要差得多，而且 CPU 对此类事情的硬件支持也较少。他们在前缀和后缀增量之间来回切换的不一致、看似随机的方式也表明代码是为糟糕的编译器编写的。

除了过早的优化外，代码完全是意大利面条，没有任何合理的解释。完全没有注释也表明代码是由糟糕的程序员编写的。

所以总而言之，他们以这种方式编写代码可能有也可能没有各种历史原因，但代码中有很多糟糕的编程实践，不能被视为过早的优化。

只需将该代码视为垃圾即可。

---

另请注意，strncpy 函数主要已过时，应避免使用。 strncpy 仅用于 Unix 中的一种古老的字符串格式。 It was never intended to be a safe version of strcpy .相反，该函数是危险的，并且已知会由于意外丢失空终止符而导致大量错误。

strncpy 的标准规范也迫使它做很多毫无意义的事情，比如在你事先知道长度的情况下检查空终止。此外，人们可能想知道用更多的 \0 填充第一个 \0 之后的剩余字符有什么好处。所有这些毫无意义的要求都会使函数不必要地变慢。

因此，没有理由在现代 C 代码中的任何地方使用 strncpy。复制已知长度字符串的正确方法是这样的:

memcpy(str1, str2, str2len + 1);