为什么strlen()的实现有效?

时间:2013-12-01 12:58:45

标签: c undefined-behavior

(免责声明:我见过this question,我并没有重新询问它 - 我对为什么代码有效感兴趣,并且没有 的工作原理。)

所以here's这个Apple的实现(好吧,FreeBSD)strlen()。它使用一个众所周知的优化技巧,即它一次检查4或8个字节,而不是与0进行逐字节比较:

size_t strlen(const char *str)
{
    const char *p;
    const unsigned long *lp;

    /* Skip the first few bytes until we have an aligned p */
    for (p = str; (uintptr_t)p & LONGPTR_MASK; p++)
        if (*p == '\0')
            return (p - str);

    /* Scan the rest of the string using word sized operation */
    for (lp = (const unsigned long *)p; ; lp++)
        if ((*lp - mask01) & mask80) {
        p = (const char *)(lp);
        testbyte(0);
        testbyte(1);
        testbyte(2);
        testbyte(3);
#if (LONG_BIT >= 64)
        testbyte(4);
        testbyte(5);
        testbyte(6);
        testbyte(7);
#endif
    }

    /* NOTREACHED */
    return (0);
}

现在我的问题是:也许我错过了明显的,但是这不能读到字符串的结尾吗?如果我们有一个长度不能被字大小整除的字符串怎么办?想象一下以下场景:

|<---------------- all your memories are belong to us --------------->|<-- not our memory -->
+-------------+-------------+-------------+-------------+-------------+ - -
|     'A'     |     'B'     |     'C'     |     'D'     |      0      |
+-------------+-------------+-------------+-------------+-------------+ - -
^                                                      ^^
|                                                      ||
+------------------------------------------------------++-------------- - -
                       long word #1                      long word #2

当读取第二个长字时,程序会访问实际上不应该访问的字节...这不是错误的吗?我非常有信心Apple和BSD的人知道他们在做什么,所以有人可以解释为什么这是正确的吗?

我注意到的一件事是beerboy asserted this to be undefined behavior,我也相信它确实存在,但是他被告知它不是,因为“我们将字符大小与初始for循环对齐”(不是这里显示)。但是,我根本没有看到为什么如果数组不够长并且我们正在读取它的末尾,那么对齐将是任何相关的。

2 个答案:

答案 0 :(得分:21)

虽然这在技术上是未定义的行为,但实际上没有本机架构以比字大小更精细的粒度检查越界内存访问。因此,虽然通过终结器的垃圾可能最终被读取,但结果不会是崩溃。

答案 1 :(得分:4)

  

我根本没有看到为什么如果数组不够长并且我们正在阅读其末尾,那么对齐将是任何相关的。

例程从对齐字边界开始有两个原因:首先,在大多数体系结构上读取对齐地址中的字更快(并且在几个CPU上它也是强制)。速度提升足以在大量类似的操作中使用相同的技巧:memcpy,strcpy,memmove,memchr等。

第二:如果你继续从单词边界开始阅读单词,你可以确信其余的字符串都位于同一个内存页面中。字符串(包括其终止零)不能跨越存储器页边界,也不能读取单词。 (1)

所以这总是最快和最安全的,即使内存页面粒度是sizeof(LONG_BIT)(它不是)。

在字符串末尾附近拾取整个单词可能会在最后的零之后拾取额外的字节,但是从有效内存中读取未定义的字节不是UB - 仅对其内容起作用是(2)。如果该字在内部任何地方都包含零终止符,则使用test_byte检查各个字节,并且如原始源中所示,这将永远在终结符后的字节上。< / p>

(1)显然他们可以,但我的意思是“永远不会进入锁定的页面”或类似的东西。

(2)正在讨论中。在Sneftel的回答下看到(对不起!)。