My favorite gcc trick is to compile and run the following two line, and then try to reconcile the results.
x = 7;
printf("%d %d %d",x++,++x,x++);
x = 7;
printf("%d %d %d",x++,x=2,x++);
Go ahead, try it, run it, and explain the output.
x = 7;
printf("%d %d %d",x++,++x,x++);
x = 7;
printf("%d %d %d",x++,x=2,x++);
Go ahead, try it, run it, and explain the output.
https://www.securecoding.cert.org/confluence/display/seccode...
Basically, do not depend on the order of evaluation of arguments to a function call, because it is unspecified and left to the implementation to decide according to the C99 standard.
EDIT: Another explanation, pertinent to your example can be found here - http://c-faq.com/expr/evalorder2.html
The output should be (at least from my understanding and what PHP renders): 7 9 9 7 2 2
As far as reconciliation, I guess the first line makes sense when you think about it as machine code and how the pointers probably behave. The second line though, seems quite evil and I am going to go hide under my "Rails will save me" blanket until someone can explain this voodoo.
2,3,7 are all valid possibilities for the 4th and 6th numbers, but apparently gcc interprets the 5th as 2 + 1 somehow, which I can't see as being valid whatsoever.
It should be noted that this is illegal C, and compilers are allowed to do absolutely anything they want when they see it. Even things that are totally not logical.
Also, it's not illegal C, it's undefined C and compilers are only allowed to do whatever they want within the undefined area (which is larger than I expected.)
Undefined is not the same as implementation defined.
movl $7, -4(%rbp)
movl -4(%rbp), %ecx
addl $1, -4(%rbp)
movl $2, -4(%rbp)
movl -4(%rbp), %esi
addl $1, -4(%rbp)
movl -4(%rbp), %edx
movl $.LC0, %edi
movl $0, %eax
call printf