Compound Assignment Operators in C

Question

What is the output of the following program, and why?

#include<stdio.h>
#include<conio.h>
int main()
{
    int a=5;
    a +=a += a += 2;
    printf("%d",a);
    getch();
    return 0;
}

Answer 1

The behaviour of your program is undefined as you are reading from and writing to a in an unsequenced step.

---

What your ancient compiler is doing is correctly following the C grammar rules and is grouping the expression as

a += (a += (a += 2))

But grouping is not the same as sequencing. From this point the behaviour is undefined. Your compiler appears to evaluate the above to

a += (a += 7)

followed by

a += 14

to yield 28.

Answer 2

This is a tough question without an easy, obvious answer.

The expression is probably undefined, in which case it's meaningless to ask "what could be the possible output?", because it could be anything.

If it's undefined, it's because there are multiple writes (stores) to a without any intervening sequence points. The rightmost a += 2 computes 7 and prepares to store it into a. Next we have the middle a +=, which tries to take the 7 and add it to... what? The old or the new value of a? If it's the old we compute 5+7= 12 and if it's the new we compute 7+7=14, and whichever value we compute, we prepare to store it into a, but does it "win" and overwrite the value that the rightmost a += 2 tried to store, or not? And then the arguments (and the multiplicity of different interpretations and possible answers) proliferate for the leftmost a +=.

Not all assignment expressions are undefined, of course. For example, the old standby

a = a + 1

is well-defined. It both fetches from a and assigns to a, but in this case we don't have to ask, "what if it assigns to a before it fetches from it?", because obviously, it has to fetch from a first, in the process of computing the new value to be assigned. But this argument doesn't rescue a += a += 2, I don't think.

There are newer rules about "sequencing" which do away with the old concept of "sequence points", and the new rules might render this expression well-defined, but I'm not sure.

Unless you're interested in frustrating, head-banging puzzles, it's best to steer clear of expressions like this one. You obviously wouldn't have any use for an expression like this in a real program. It's nearly impossible to figure out (a) if the expression is well-defined and (b) if so, what it's supposed to do, so a program containing an expression like this is unmaintainable; you have to be a hard-core language lawyer to properly understand it.

Naturally it's important to understand how simpler, saner expressions like a += 2 or x += y[i++] work. But for something insane like a += a += a += 2, don't fall into the trap of asking "Wouldn't it help me understand C better if I understand what it means?", because the only thing to understand is that it's borderline, if not absolutely, meaningless.

See also SO's canonical entry on undefined expressions, Why are these constructs (using ++) undefined behavior in C? (although none of the answers there cover this particular case).

Answer 3

It depends on the compiler ! But theoretically 28 is the answer ! The assignment will be from right to left so a +=a += a += 2; can be break down as

5+2=7 a+=2
7+7=14 a+=a+=2
14+14=28 a+=a+=a+=2