4

Possible Duplicate:
Could anyone explain these undefined behaviors (i = i++ + ++i , i = i++, etc…)

I'm having my lecturer class right now and my lecturer mention an expression as follows:

int a , b;
a = 4;
b = a++ + a--;

The Question

My lecturer says this expression value can be defined: that it is 8. Which means both a value 4 is summed and assign to b before it's incremented and decremented.

But to me, I think this expression answer is kinda vague and the result will be based on the compiler implementation. That's because to me, the compiler might do the a++ part first—that is, use the value 4 and incremented the a to 5, after that the expression is 4 + 5 = 9 and is assigned to b then only the a is decremented.

It might also do the a-- part first by using the value 4 and decremented it by 1 to 3, and later on sum the value 4 with 3 and assign the value to b then only incremented the a back to 4.

My question is who's correct, my lecturer or me? Because I don't wanna get confused with it and later on will be a problem for me.

Community
  • 1
  • 1
caramel1995
  • 2,968
  • 10
  • 44
  • 57
  • 1
    It's undefined behavior, so your lecturer is wrong. I'll let someone else explain why in more details, as I don't have the standard with me. – Etienne de Martel Oct 24 '11 at 01:53
  • 1
    See [Could anyone explain these undefined behaviors (i = i++ + ++i , i = i++, etc...)](http://stackoverflow.com/questions/949433/could-anyone-explain-these-undefined-behaviors-i-i-i-i-i-etc). Long story short, you're right. `a` is modified twice without an intervening sequence point, so it's undefined. – Matthew Flaschen Oct 24 '11 at 01:54
  • +1 for doubting an incorrect authority, even though it's a dupe. – Chris Lutz Oct 24 '11 at 01:58
  • 2
    Your lecture is wrong, wrong wrong. Not only is the result of the expression depending on the (unspecified) order of evaluation, the entire behavior of the program is undefined. As far as the language standard is concerned, the output could be a suffusion of yellow. Oh, and your question is about to be closed as a duplicate (this gets asked *a lot*). – Keith Thompson Oct 24 '11 at 02:02
  • Exact duplicate of so much questions. – Daniel Oct 24 '11 at 02:04
  • @KeithThompson - The "suffusion of yellow" bit made me laugh, but it is much tamer than the canonical [nasal demons](http://catb.org/jargon/html/N/nasal-demons.html) – Chris Lutz Oct 24 '11 at 02:10

1 Answers1

9

Your lecturer is wrong. Writing to the same variable twice without an intervening sequence point is undefined behaviour. From the spec, J.2 Undefined behaviour:

Between two sequence points, an object is modified more than once, or is modified and the prior value is read other than to determine the value to be stored (6.5).

The reference is to 6.5 Expressions, paragraph 5:

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.

Annex C of the C spec has a handy list of all of the sequence points:

The following are the sequence points described in 5.1.2.3:

  • The call to a function, after the arguments have been evaluated (6.5.2.2).
  • The end of the first operand of the following operators: logical AND && (6.5.13); logical OR || (6.5.14); conditional ? (6.5.15); comma , (6.5.17).
  • The end of a full declarator: declarators (6.7.5);
  • The end of a full expression: an initializer (6.7.8); the expression in an expression statement (6.8.3); the controlling expression of a selection statement (if or switch) (6.8.4); the controlling expression of a while or do statement (6.8.5); each of the expressions of a for statement (6.8.5.3); the expression in a return statement (6.8.6.4).
  • Immediately before a library function returns (7.1.4).
  • After the actions associated with each formatted input/output function conversion specifier (7.19.6, 7.24.2).
  • Immediately before and immediately after each call to a comparison function, and also between any call to a comparison function and any movement of the objects passed as arguments to that call (7.20.5).
Community
  • 1
  • 1
Carl Norum
  • 219,201
  • 40
  • 422
  • 469
  • He's not only wrong, he's misleading. That's much worse. – Etienne de Martel Oct 24 '11 at 01:56
  • Hey, I have a question here. Since standard says that an object can be modified only once, why is the professor incorrect? According to his approach, the object is modified only once. Furthermore, that is the only way too to calculate the expression using this rule. So, shouldn't it be deemed defined behaviour? – Anurag Kalia Dec 30 '12 at 04:50
  • @Anurag, I'm not sure I follow what you're asking. Both `a++` and `a--` have to be evaluated before adding their results, and both of those require writing to `a`. – Carl Norum Dec 30 '12 at 05:31
  • Sorry, I was reading the standard from the angle of compiler and I sort of get it now that I have searched around a bit more. Plus, the second line of 6.5 already renders it undefined. Yet, for the sake of clarification, is `a++ + a--;` (without any leading initialisation to b) too non-standard? My guess is that it is because it tries to modify value twice, without any sequence point in-between. – Anurag Kalia Dec 30 '12 at 14:48
  • Yes, that's also undefined behaviour. – Carl Norum Dec 30 '12 at 16:16