行为通常被指定为未定义，如果有一些可以想象的原因，为什么一个试图“有帮助”的编译器可能会做一些完全意想不到的行为。

In the case where a variable is written multiple times with nothing to ensure that the writes happen at distinct times, some kinds of hardware might allow multiple "store" operations to be performed simultaneously to different addresses using a dual-port memory. However, some dual-port memories expressly forbid the scenario where two stores hit the same address simultaneously, regardless of whether or not the values written match. If a compiler for such a machine notices two unsequenced attempts to write the same variable, it might either refuse to compile or ensure that the two writes cannot get scheduled simultaneously. But if one or both of the accesses is via a pointer or reference, the compiler might not always be able to tell whether both writes might hit the same storage location. In that case, it might schedule the writes simultaneously, causing a hardware trap on the access attempt.

当然，有人可能会在这样的平台上实现C编译器，但这并不意味着在硬件平台上使用小到可以被原子处理的类型存储时不应该定义这种行为。试图以无序的方式存储两个不同的值可能会导致奇怪，如果编译器没有意识到它;例如，给定:

uint8_t v;  // Global

void hey(uint8_t *p)
{
  moo(v=5, (*p)=6);
  zoo(v);
  zoo(v);
}

if the compiler in-lines the call to "moo" and can tell it doesn't modify "v", it might store a 5 to v, then store a 6 to *p, then pass 5 to "zoo", and then pass the contents of v to "zoo". If "zoo" doesn't modify "v", there should be no way the two calls should be passed different values, but that could easily happen anyway. On the other hand, in cases where both stores would write the same value, such weirdness could not occur and there would on most platforms be no sensible reason for an implementation to do anything weird. Unfortunately, some compiler writers don't need any excuse for silly behaviors beyond "because the Standard allows it", so even those cases aren't safe.

在这种情况下，结果在大多数实现中都是相同的，这是偶然的;求值的顺序仍未确定。考虑f(i = -1, i = -2):这里，顺序很重要。在你的例子中，这无关紧要的唯一原因是两个值都是-1。

假定表达式被指定为具有未定义行为的表达式，恶意兼容的编译器可能在计算f(i = -1, i = -1)并中止执行时显示不适当的映像，但仍然被认为是完全正确的。幸运的是，据我所知，没有编译器这样做。

行为通常被指定为未定义，如果有一些可以想象的原因，为什么一个试图“有帮助”的编译器可能会做一些完全意想不到的行为。

In the case where a variable is written multiple times with nothing to ensure that the writes happen at distinct times, some kinds of hardware might allow multiple "store" operations to be performed simultaneously to different addresses using a dual-port memory. However, some dual-port memories expressly forbid the scenario where two stores hit the same address simultaneously, regardless of whether or not the values written match. If a compiler for such a machine notices two unsequenced attempts to write the same variable, it might either refuse to compile or ensure that the two writes cannot get scheduled simultaneously. But if one or both of the accesses is via a pointer or reference, the compiler might not always be able to tell whether both writes might hit the same storage location. In that case, it might schedule the writes simultaneously, causing a hardware trap on the access attempt.

当然，有人可能会在这样的平台上实现C编译器，但这并不意味着在硬件平台上使用小到可以被原子处理的类型存储时不应该定义这种行为。试图以无序的方式存储两个不同的值可能会导致奇怪，如果编译器没有意识到它;例如，给定:

uint8_t v;  // Global

void hey(uint8_t *p)
{
  moo(v=5, (*p)=6);
  zoo(v);
  zoo(v);
}

if the compiler in-lines the call to "moo" and can tell it doesn't modify "v", it might store a 5 to v, then store a 6 to *p, then pass 5 to "zoo", and then pass the contents of v to "zoo". If "zoo" doesn't modify "v", there should be no way the two calls should be passed different values, but that could easily happen anyway. On the other hand, in cases where both stores would write the same value, such weirdness could not occur and there would on most platforms be no sensible reason for an implementation to do anything weird. Unfortunately, some compiler writers don't need any excuse for silly behaviors beyond "because the Standard allows it", so even those cases aren't safe.

在我看来，关于函数参数表达式排序的唯一规则是:

3)当调用一个函数时(无论该函数是否内联，以及是否使用显式函数调用语法)，与任何参数表达式或指定被调用函数的后缀表达式相关的每一个值计算和副作用，都在被调用函数体中的每一个表达式或语句执行之前进行排序。

这并没有定义参数表达式之间的排序，所以我们最终会得到这样的结果:

1)如果一个标量对象上的副作用相对于同一标量对象上的另一个副作用是未排序的，则该行为是未定义的。

实际上，在大多数编译器上，您引用的示例都可以正常运行(而不是“擦除您的硬盘”和其他理论上未定义的行为结果)。 然而，这是一种负担，因为它取决于特定的编译器行为，即使分配的两个值是相同的。此外，很明显，如果你试图分配不同的值，结果将是“真正的”未定义:

void f(int l, int r) {
    return l < -1;
}
auto b = f(i = -1, i = -2);
if (b) {
    formatDisk();
}

由于操作是无序的，因此执行赋值的指令不能交叉。这样做可能是最佳的，这取决于CPU架构。参考页面说明如下:

If A is not sequenced before B and B is not sequenced before A, then two possibilities exist: evaluations of A and B are unsequenced: they may be performed in any order and may overlap (within a single thread of execution, the compiler may interleave the CPU instructions that comprise A and B) evaluations of A and B are indeterminately-sequenced: they may be performed in any order but may not overlap: either A will be complete before B, or B will be complete before A. The order may be the opposite the next time the same expression is evaluated.

这本身似乎不会造成问题——假设正在执行的操作是将值-1存储到内存位置。但是，编译器不能将其优化为具有相同效果的单独指令集，但如果该操作与同一内存位置上的另一个操作交织在一起，则可能会失败。

例如，想象一下，与将值-1载入内存相比，先将内存归零，再将其递减更有效。那么这个:

f(i=-1, i=-1)

可能成为:

clear i
clear i
decr i
decr i

现在i是-2。

这可能是一个虚假的例子，但它是可能的。

令人困惑的是，将一个常量值存储到一个局部变量中并不是C设计用于运行的每个架构上的一个原子指令。在这种情况下，运行代码的处理器比编译器更重要。例如，在ARM上，每条指令都不能携带一个完整的32位常量，在一个变量中存储一个int就需要更多的指令。这个伪代码的例子，你一次只能存储8位，并且必须在32位寄存器中工作，i是一个int32:

reg = 0xFF; // first instruction
reg |= 0xFF00; // second
reg |= 0xFF0000; // third
reg |= 0xFF000000; // fourth
i = reg; // last

你可以想象，如果编译器想要优化它，它可能会将相同的序列交叉两次，你不知道什么值会被写入i;假设他不太聪明

reg = 0xFF;
reg |= 0xFF00;
reg |= 0xFF0000;
reg = 0xFF;
reg |= 0xFF000000;
i = reg; // writes 0xFF0000FF == -16776961
reg |= 0xFF00;
reg |= 0xFF0000;
reg |= 0xFF000000;
i = reg; // writes 0xFFFFFFFF == -1

然而，在我的测试中，gcc足够友好，可以识别相同的值被使用了两次，并生成它一次，没有任何奇怪的事情。得到-1和-1 但我的例子仍然是有效的，因为重要的是要考虑到即使是常数也可能不像它看起来那么明显。