1. 是的,C实现(不仅仅是编译器)包括标准库、链接和运行时支持,和/或其他用于实现C的工具,它产生相同的可观察行为。 ^一 作为一个一致的抽象机器是一致的。标准中的所有其他要求和段落不仅仅是额外的。它们定义了抽象机器的行为,因此它们有助于描述可观察的行为必须是什么。

2. 是的,没有可观察行为的程序可以优化为只返回的程序。注意 the standard does not actually include exit status in observable behavior 所以 xor eax, eax 技术上不需要。然而,这可能只是标准中的一个无意的缺陷,而不是意图。

笔记

^一 程序的行为不是规范所要求的唯一事情。例如,实现还必须记录各种实现定义的行为。因此,这个假设的C实现与一些抽象机的行为相同,它还必须包含所需的文档。

是的,你是对的。编译器可以做它想做的, 如果观察到的行为与抽象机器所能产生的行为相同 . 但这本身并不是戏剧性的:为什么我们会关心一些不能被观察到的东西?这是优化编译器的关键。

例子:

int main() {
    int a;
    for (int i=INT_MAX; i>=0; i--) {
        a = i;
    }
    printf("%d\n", a);
    return 0;
}

它将要打印的唯一可观察的行为 0 一次。因此编译器可以对循环进行优化,以产生与以下相同的结果:

int main() {
    printf("%d\n", 0);
    return 0;
}

这意味着你不能使用 空的 循环来增加延迟,因为它们可以被优化,根本不会产生延迟。

imho最显著的副作用,如果允许编译器假设程序中不会发生未定义的行为。

第二个例子:

int main() {
    struct {
        int a[16];
        int b[16];
    } s;

    for (i=0; i<16; i++) {
        s.a[i] = i;
        s.b[i] = 2 * i;
    }
    for (i=0; i<32; i++) {
        printf(" %d", s.a[i]);      // UB array access past upper bound
    }
    printf("\n");
    return 0;
}

幼稚的编译器应该显示0到31之间的所有数字,因为我们知道数组 s.a 和 s.b 应该是相邻的,指针算术应该给出 &(s.b[0]) == &(s.a[16]) . 但是优化编译器可以注意到 S.B 如果不涉及UB并且可以自由地优化 S.B 阵列访问,甚至优化 b 成员。这里需要崩溃或随机值…更糟糕的是,一个非常聪明的编译器可能会注意到打印循环中存在过去绑定的访问。从这一点来看,程序行为是未定义的,例如,编译器可以在打印16 st值后停止循环。没有错误,但只打印了16个值…