之前只有一篇关于较早版本的 strlen(3) 实现的笔记，这里补上我在 2010 年做的新增改进。

与 Pascal 等语言不同，C 的字符串并不保存串的长度，而是在字符串末尾以 nul 字符（’\0’）来表示字符串结束。这个设计决策是上世纪 60 年代作出的，有都市传说是为了省几个字节的空间，不过我个人认为也可能是因为汇编里面到处都是判断是否碰到了 0 的操作。不管怎么说，这个设计令 strlen 变成了一个 O(n) 的操作。

早期的 BSD Unix 采用的 strlen 是非常简单的循环比较每一个字符是不是 nul。1993年，J.T. Conklin 为 i386 系统撰写了一个汇编的版本，这个版本的核心用的是 REP SCASB，实际上和 C 版本的算法是一样的（不知道为什么 C 编译器不能写出同样的代码）。

为了配合 x86_64 平台，后来又有了一个新的汇编版本，这个版本的核心算法是按字匹配，找到包含 nul 字符的字之后，再在其中用原始的算法找到 nul 字符。

我在 2009 年根据这个 x86_64 版本的汇编的思路重写了一个 C 的版本，并在 2010 年做了一次最终的变动，形成了目前的版本。这个版本的大致流程如下：

• 判断第一个字中是否存在 nul，如果存在，扫描查找其中有效位置的 nul 字符；
• 按字扫描剩余的字符串；如果发现字中带 nul，则扫描并返回其位置。

实现细节

整个算法中，比较难理解的是判断字中是否带 nul 字符。具体的方法是计算两个中间变量：

1. a = (x - 0x01010101)
2. b = (~x & 0x80808080)
3. 计算 a & b == 0

这里的 0x01010101 和 0x80808080 可以进一步扩展。第一步，如果每个字节都 <= 0x7f，只要那个字节不是 0，做差必然得到一个 < 0x80 的结果（换言之，最高位是0）；如果有字节 >= 0x81，做差必然得到一个 > 0x80 的结果。对于等于 0x80 的情况，我们会得到 0x7f，但这并不重要。

注意到，此处，任何一个字节的最高 bit 是 1 的话，则必然是前面两种情况之一：要么这个字节是 0，要么它 >= 0x81。如果不考虑后一种情况，我们直接把结果 & 0x80808080 即可；然而，由于需要考虑后一种情况，我们接着计算 ~x & 0x80808080。若某一字节 >= 0x80，则对应的结果将是那个位置上的一个 0x80。

将两个结果做逻辑与，若结果非 0 则说明至少有一个字节是 nul。

这里说起来的过程很复杂，但事实上计算机计算这些要比一个一个去判断每个字节是否为 0 要快。这里有几方面的原因：

• 按字长做操作，令 CPU 无需模拟按字节为长度操作的情况，后者是比较耗时的；
• 前两步操作（分别计算a, b）可以并发执行；
• 最后一步操作可以直接在两个寄存器之间进行，且是速度较快的与运算；

在实际的实现中，还有一些其他的技巧。

第一个技巧是，从第一个小节就开始用字长的操作。一般来说，内存分配器在分配内存时是以字边界开始的，因此，通常 strlen() 的操作的指针都是对齐的。不过，即使不是，这个指针往前退到第一个整字位置（例如字长=8，指针 0x9，则退回 0x8）开始的一个整字必然是在同一个内存页上，因此这个访问不会越界。如果在这个整字中有 nul 字符，我们只需从指针开始处扫描到第一个整字结尾的地方即可知道是不是真的找到了字符串的末尾。

由于整个字已经在处理器缓存中，后续的循环也不会太慢。

第二个技巧与此类似，我们一直都用整字的操作。如果字的起始地址在内存页中，则终止地址也必然在同一个内存页中。这个访问同样也不会发生意外越界（尽管在分配内存时可能出现类似分配了 4 个字节，但访问了 8 个字节的情况）。换言之，如果程序原先不会发生越界异常，则现在也不会。

这个版本的 strlen 源代码可以在 这里 找到。