In a C function call, in which order are the parameters passed/evaluated?

Question

I am running this C program:

#include<stdio.h>

void print(int* a, int* b, int* c, int* d, int* e)
{
    printf("%d %d %d %d %d\n", *a, *b, *c, *d, *e);
}

int main()
{
    static int a[] = {97, 98, 99, 100, 101, 102};
    int* ptr = a + 1;

    print(++ptr, ptr--, ptr, ptr++, ++ptr);
    ptr = a+ 1;
    printf("%d %d %d %d %d\n", *++ptr, *ptr--, *ptr, *ptr++, *++ptr);

    int i = 0;
    printf("%d %d %d", i++, ++i, ++i);
}

One compiler prints this as the output:

99 99 98 98 100
99 99 98 98 100
0 2 3

Another compiler prints this:

100 100 100 99 100
100 100 100 99 99
2 3 3

Now, I am confused what is happening. What is the correct order?

There is no correct order. C compilers are free to do what they choose, and code that relies on it is [undefined behavior](https://stackoverflow.com/questions/2397984/undefined-unspecified-and-implementation-defined-behavior) (Link is for C++ but the definition is the same) — Silvio Mayolo, Mar 04 '22 at 15:09
See [C11 6.5.2.2p10](https://port70.net/~nsz/c/c11/n1570.html#6.5.2.2p10) — pmg, Mar 04 '22 at 15:21
It's very tempting to make this a duplicate of [Why are these constructs using pre- and post-increment undefined behaviour?](https://stackoverflow.com/questions/949433/why-are-these-constructs-using-pre-and-post-increment-undefined-behavior) However, this is about evaluation order which is only part of the issue in that question. The code here definitely has the problems described in the linked question — but if the question used fully-legitimate arguments (no side-effects) in the argument lists, there would still be a valid issue "what order are the arguments evaluated", which is unspecified. — Jonathan Leffler, Mar 04 '22 at 17:11

score 3 · Accepted Answer · answered Mar 04 '22 at 15:46

Evaluation of function calls is specified in the 2018 version of the C standard clause 6.5.2.2, but this clause does not specify the order of evaluation of the arguments. Any order is permitted.

As a consequence of this, the behavior of print(++ptr, ptr--, ptr, ptr++, ++ptr); is not defined by the C standard. 6.5 2 says:

If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. If there are multiple allowable orderings of the subexpressions of an expression, the behavior is undefined if such an unsequenced side effect occurs in any of the orderings.

ptr is a scalar object. (C 2018 6.2.5 21 says “Arithmetic types and pointer types are collectively called scalar types.”) ++ptr and ptr-- change ptr by a side effect. (The “main” effect of ++ptr is to evaluate to the incremented value of ptr. Its side effect is to update the stored value of ptr.) Since there is no ordering imposed on these side effects, the conditions of 6.5 2 are satisfied, so it applies, and the behavior is not defined by the C standard.

Note that this does not just mean that ptr may be updated in whatever order the compiler happens to choose. When the C standard says behavior is undefined, that means it does not impose any requirements on the behavior at all. Two updates to the object might conflict, updating different bytes of it in different orders, producing a value that is impossible to obtain by separate consecutive updates in any order. (This could happen, for example, when a compiler implements four-byte pointers using two-byte updates in a primitive machine.) Or the optimizer in the compiler could recognize the code does not have defined behavior and remove it completely from the program or replace it by other code. (For example, if the program contains a branch between two sequences of code, and the optimizer recognizes one branch would have undefined behavior in a particular circumstances, it can omit the code that evaluates the choice and use only the code on the other branch.)

In a C function call, in which order are the parameters passed/evaluated?

1 Answers1