Honest to a Segfault

mov lhs_result, i     ; Copy the values of the postincrement evaluation.
mov rhs_result, i     ; (Which is the original value of i.)
mul result, lhs_result, rhs_result
add i, lhs_result, 1
add i, rhs_result, 1  ; Second increment clobbers with the same value!

mov lhs_result, i ; Gets the original 11.
inc i             ; Increment in-place after the start value is copied.
mov rhs_result, i ; Gets the new value 12.
inc i             ; Increment occurs in-place again, making 13.
mul result, lhs_result, rhs_result

>>> count = 0
>>> count++
  File "<stdin>", line 1
    count++
          ^
SyntaxError: invalid syntax

>>> count = 0
>>> ++count
0
>>> --count
0

#include <stdio.h>
 
int identity(int value) { return value; }
 
int main() {
        int i = 11;
        printf("%d\n", identity(i++) * identity(i++));
        printf("%d\n", i);
        return 0;
}

7 Responses to “Two postfix operations redux: sequence points”

1. Michał Bartoszkiewicz Says:
   January 10th, 2010 at 16:54

   Are you sure the C compiler isn’t allowed to interpret identity(i++) * identity(i++) as (tmp1 = i, tmp2 = i, i = tmp1 + 1, i = tmp2 + 1, identity(tmp1) * identity(tmp2)) and print 121, 12?
   gcc seems to warn on this code when invoked with -Wsequence-point:

   x.c:7: warning: operation on 'i' may be undefined

2. cdleary Says:
   January 10th, 2010 at 17:12

   @Michał: That’s actually a very interesting question that I don’t know the answer to (I see the same warning). Section 6.5 (Expressions) item 3 states, “[T]he order of evaluation of subexpressions and the order in which side effects take place are both unspecified,” which implies to me an that there is a definitive ordering of subexpression evaluation, it’s just unspecified which order it is. That could be a misinterpretation, though.

   I guess we’d have to read through GCC to figure out why it’s giving that particular warning. This stuff is just too hokey to resolve from precise wording in the specifications. :-)

3. Dan Villiom Podlaski Christiansen Says:
   January 11th, 2010 at 03:43

   I believe ‘undefined’ and ‘unspecified’ mean exactly that; the result of the expression may vary depending on the compiler used, and possibly what it’s targeting too.

   For example, see this comparison of compiling your test program in Clang, Apple GCC & LLVM GCC.

   % clang -O3 -Wall -Wextra test.c&& ./a.out
   132
   13
   % gcc -O3 -Wall -Wextra test.c&& ./a.out
   test.c: In function ‘main’:
   test.c:7: warning: operation on ‘z’ may be undefined
   121
   12
   % llvm-gcc -O3 -Wall -Wextra test.c&& ./a.out
   test.c: In function ‘main’:
   test.c:7: warning: operation on ‘z’ may be undefined
   121
   12

4. cdleary Says:
   January 13th, 2010 at 18:39

   @Dan: Your evidence has bested my finest lawyering. :-)

   Apparently the subexpressions can be evaluated concurrently. I’ll update the entry now to fix the mistake.

5. Dan Villiom Podlaski Christiansen Says:
   January 14th, 2010 at 01:33

   Actually, a similar issue once bit me. What would you expect the code at the bottom of this post to print?

   The results:

   % clang ./test.c
   % ./a.out
   putint(1)
   putint(2)
   printvars(1, 2)
   % gcc ./test.c
   % ./a.out
   putint(2)
   putint(1)
   printvars(1, 2)

   As part of a compiler course, I once wrote a VM in C, and — for brevity — I had function call sites as arguments of another function call. Later, I wanted to try — for fun — to compile the code with the IBM XLC compiler. The unexpected evaluation ordering function arguments caused the VM to crash. (This was in 2003, I believe.)

   The lesson I learned from that is that you shouldn’t make assumptions about when a C compiler decides to do what. Surprisingly large parts of the C language are unspecified, which in effect means implementation-defined; that is, you get what you, at the discretion of the compiler.

   I never engaged much in language lawyering, for some reason, and it never really appealed to me. My best guess is that it’s because I tend to distrust my own conclusions :-)

   #include <stdio.h>
    
   void printvars(int a, int b)
   {
       printf("%s(%d, %d)\n", __func__, a, b);
   }
    
   int putint(int i)
   {
       printf("%s(%d)\n", __func__, i);
       return i;
   }
    
   int main(int argc, const char *argv[])
   {
       printvars(putint(1), putint(2));
   }

6. Dan Villiom Podlaski Christiansen Says:
   January 14th, 2010 at 01:44

   I may have remembered wrong, considering the following results:

   % for i in gcc clang; for a in i386 ppc; print -l '' "$i ($a)" && $i -arch $a ./test.c && ./a.out && rm ./a.out
   
   gcc (i386)
   putint(2)
   putint(1)
   printvars(1, 2)
   
   gcc (ppc)
   putint(1)
   putint(2)
   printvars(1, 2)
   
   clang (i386)
   putint(1)
   putint(2)
   printvars(1, 2)
   
   clang (ppc)
   putint(1)
   putint(2)
   printvars(1, 2)

   As you can see, the evaluation order of function arguments of GCC varies depending on the architecture targeted. Rather than when trying XLC, it might have been when I tried to run the code on my Mac at home that I ran into this. Nonetheless, the fact that the evaluation order is changed by simple retargeting of the compiler underscores exactly what ‘unspecified’ and ‘undefined’ mean for portability…

7. cdleary Says:
   January 14th, 2010 at 16:19

   @Dan: Yeah, I don’t see language lawyering as a good thing, it’s just a funny concept that engineers will hang on every word of a spec, as I have just done. Nice examples of code that doesn’t port! The intuition that program order is strictly top-to-bottom and left-to-right is certainly hard to overcome at times.

Leave a Reply