tags:

views:

84

answers:

5
+2  A: 

None of the outputs can really qualify as unexpected. All the arguments to a function are evaluated before entry to the function itself -- but the order of their evaluation relative to each other is unspecified, so all of these results are allowed. Officially, your last one (that has two separate instances of incrementing a) has undefined behavior, so it doesn't have to do anything sensible at all.

Jerry Coffin
If there is a sequence point between evaluating each argument, why should the last one in particular be more wrong than the others?
UncleBens
The last one is "more wrong" because it modifies `a` twice without an intervening sequence point. The rest only modify `a` once.
Jerry Coffin
@UncleBens: there isn't a sequence point between evaluating each argument. There is a sequence call after the operands have been evaluated and before the function is called, but there are no sequence points (in the exmple) while the arguments are being evaluated.
Jonathan Leffler
@Jerry: I think that even the calls with a single increment applied to 'a' are undefined behaviour too - not just the one with two increments applied.
Jonathan Leffler
@Johathon: That's open to some argument. The exact wording from the standard (§6.5/2) is: "Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored." I've seen (and participated in) several arguments on comp.std.c about whether that makes (code like) the others UB or not. In the end, nobody seems quite sure, but nobody can come up with wording that would make it clear either.
Jerry Coffin
Well, g++ says for `printf("%d %d", a, ++a);` that the operation on a "may be" undefined - not unspecified. (That's in C++ mode, but would the languages really differ here?!)
UncleBens
@UncleBens: That message sounds pretty accurate. The last one is clearly UB; the others might be, depending on interpretation.
Jerry Coffin
+1  A: 

Function parameters are not evaluated in a defined order in C. Therefore one cannot tell beforehand if a or a++ will be evaluated first when calling printf.

See http://stackoverflow.com/questions/376278/parameter-evaluation-order-before-a-function-calling-in-c/376288#376288

Hans W
+2  A: 

You are invoking undefined behaviour by referencing both 'a' and 'a++' in the argument list.

It is not defined which order the arguments are evaluated in. Different compilers may choose different orders. A single compiler can choose different orders at different times.

Do not do it!

Jonathan Leffler
+3  A: 

Nothing goes "from right to left" in function argument evaluation. When function arguments are evaluated, the order of evaluation is unspecified and there are no sequence points between evaluating separate arguments. This means that there's absolutely no temporal ordering in this process. The arguments can be evaluated in any order, and the process of their evaluation can be intertwined in any way.

However, your code suffers from even worse problems. All three statements that call printf produce undefined behavior (UB) because they either make an attempt to modify the same object (a) twice without a sequence point between the modifications (the third call), or they attempt to modify an object and read it for an independent purpose (the first and the second call). So, it is too early to even mention the order of evaluation. Your code's behavior is undefined.

AndreyT
A: 

++a means increment a first, and then return evaluate the expression. (a changes, and the expression evaluates as a + 1)

a++ means evaluate a (so, erm, a), and then increment it. So a is passed, but the value of a is then (ie afterwards) changed to a+1.

Martin Milan
Though the other people saying that there is no set order of evaluation are also correct - I've just tried to explain the postfix and prefix operators...
Martin Milan