#include <stdio.h>
int main(void)
{
int i = 0;
i = i++ + ++i;
printf("%d\n", i); // 3
i = 1;
i = (i++);
printf("%d\n", i); // 2 Should be 1, no ?
volatile int u = 0;
u = u++ + ++u;
printf("%d\n", u); // 1
u = 1;
u = (u++);
printf("%d\n", u); // 2 Should also be one, no ?
register int v = 0;
v = v++ + ++v;
printf("%d\n", v); // 3 (Should be the same as u ?)
int w = 0;
printf("%d %d\n", ++w, w); // shouldn't this print 1 1
int x[2] = { 5, 8 }, y = 0;
x[y] = y ++;
printf("%d %d\n", x[0], x[1]); // shouldn't this print 0 8? or 5 0?
}
当前回答
ISO W14站点的文档n1188提供了关于这种计算的一个很好的解释。
我解释这些想法。
适用于这种情况的ISO 9899标准的主要规则是6.5p2。
在前一个序列点和下一个序列点之间，通过表达式求值，对象的存储值最多修改一次。此外，前面的值只能被读取，以确定要存储的值。
像i=i++这样的表达式中的序列点在i=i之前和i++之后。
In the paper that I quoted above it is explained that you can figure out the program as being formed by small boxes, each box containing the instructions between 2 consecutive sequence points. The sequence points are defined in annex C of the standard, in the case of i=i++ there are 2 sequence points that delimit a full-expression. Such an expression is syntactically equivalent with an entry of expression-statement in the Backus-Naur form of the grammar (a grammar is provided in annex A of the Standard).
所以盒子里的指令顺序没有明确的顺序。
i=i++
可以解释为
tmp = i
i=i+1
i = tmp
或者是
tmp = i
i = tmp
i=i+1
因为解释代码i=i++的所有这些形式都是有效的，并且都生成不同的答案，所以行为是未定义的。
因此，序列点可以从组成程序的每个方框的开始和结束处看到(方框是C语言中的原子单位)，并且在方框中，指令的顺序并不在所有情况下都是定义的。改变顺序有时会改变结果。
编辑:
其他解释这种歧义的很好的来源是c-faq网站(也出版了一本书)的条目，即这里、这里和这里。
其他回答
在https://stackoverflow.com/questions/29505280/incrementing-array-index-in-c网站上，有人问了这样一个句子:
int k[] = {0,1,2,3,4,5,6,7,8,9,10};
int i = 0;
int num;
num = k[++i+k[++i]] + k[++i];
printf("%d", num);
打印7…OP期望它打印6。
++i增量不能保证在剩余的计算之前全部完成。事实上，不同的编译器会得到不同的结果。在您提供的示例中，执行前2个++i，然后读取k[]的值，然后读取最后一个++i，然后读取k[]。
num = k[i+1]+k[i+2] + k[i+3];
i += 3
现代编译器可以很好地优化这一点。事实上，可能比您最初编写的代码更好(假设它按您希望的方式工作)。
只要编译和反汇编你的代码行，如果你如此倾向于知道它是如何得到你所得到的。
这是我从我的机器上得到的，以及我认为正在发生的事情:
$ cat evil.c
void evil(){
int i = 0;
i+= i++ + ++i;
}
$ gcc evil.c -c -o evil.bin
$ gdb evil.bin
(gdb) disassemble evil
Dump of assembler code for function evil:
0x00000000 <+0>: push %ebp
0x00000001 <+1>: mov %esp,%ebp
0x00000003 <+3>: sub $0x10,%esp
0x00000006 <+6>: movl $0x0,-0x4(%ebp) // i = 0 i = 0
0x0000000d <+13>: addl $0x1,-0x4(%ebp) // i++ i = 1
0x00000011 <+17>: mov -0x4(%ebp),%eax // j = i i = 1 j = 1
0x00000014 <+20>: add %eax,%eax // j += j i = 1 j = 2
0x00000016 <+22>: add %eax,-0x4(%ebp) // i += j i = 3
0x00000019 <+25>: addl $0x1,-0x4(%ebp) // i++ i = 4
0x0000001d <+29>: leave
0x0000001e <+30>: ret
End of assembler dump.
(我…假设0x00000014指令是某种编译器优化?)
C有未定义行为的概念，也就是说，一些语言结构在语法上是有效的，但你不能预测代码运行时的行为。
据我所知，该标准并没有明确说明为什么存在未定义行为的概念。在我看来，这只是因为语言设计者想在语义上有一些余地，而不是要求所有实现以完全相同的方式处理整数溢出，这很可能会带来严重的性能损失，他们只是让行为未定义，所以如果你编写的代码导致整数溢出，任何事情都可能发生。
那么，考虑到这一点，为什么这些是“问题”呢?语言清楚地表明，某些事情会导致未定义的行为。没有什么问题，没有什么“应该”牵涉其中。如果当其中一个涉及的变量被声明为volatile时，未定义的行为发生了变化，这并不能证明或改变任何东西。它是没有定义的;你不能对这种行为进行推理。
你最有趣的例子就是
u = (u++);
是教科书上未定义行为的例子(见维基百科关于序列点的条目)。
我认为C99标准的相关部分是6.5表达式，§2
在前一个序列点和下一个序列点之间，一个对象应该有它的存储值 由表达式求值最多修改一次。此外，先验值 应该是只读的，以确定要存储的值。
和6.5.16赋值操作符，§4:
操作数的求值顺序未指定。如果试图修改 赋值运算符的结果或在下一个序列点之后访问它的结果 行为是未定义的。
虽然任何编译器和处理器实际上都不太可能这样做，但在C标准下，编译器使用以下序列实现"i++"是合法的:
In a single operation, read `i` and lock it to prevent access until further notice
Compute (1+read_value)
In a single operation, unlock `i` and store the computed value
虽然我不认为有任何处理器支持这样的硬件，可以有效地完成这样的事情，人们可以很容易地想象这样的行为会使多线程代码更容易(例如，它将保证如果两个线程同时尝试执行上面的序列，I将增加2)，而且未来的某些处理器可能会提供类似的功能，这并不是完全不可想象的。
If the compiler were to write i++ as indicated above (legal under the standard) and were to intersperse the above instructions throughout the evaluation of the overall expression (also legal), and if it didn't happen to notice that one of the other instructions happened to access i, it would be possible (and legal) for the compiler to generate a sequence of instructions that would deadlock. To be sure, a compiler would almost certainly detect the problem in the case where the same variable i is used in both places, but if a routine accepts references to two pointers p and q, and uses (*p) and (*q) in the above expression (rather than using i twice) the compiler would not be required to recognize or avoid the deadlock that would occur if the same object's address were passed for both p and q.
