% 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…

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));
}

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

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

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. :-)

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