Are a+=k and a=a+b different in c?

Question

I tried to swap without a template and I encountered this. Are a+=k and a=a+b different? What is wrong for first case?

a += b-(b=a); // this print same value of two a and b.

a = a + b-(b=a); // this thing correctly swapped values.

If I ever saw `a += b-(b=a)` in a code review, I would seriously consider an HR referral. — William Pursell, Mar 08 '20 at 15:30
ı see it https://stackoverflow.com/questions/3624525/how-to-write-a-basic-swap-function-in-java this post then trıed in c — bilmemne, Mar 08 '20 at 15:32
There is a *lot* of bad code available on the internet. The challenge is learning to recognize it. — William Pursell, Mar 08 '20 at 15:33
`b=a` returns a, which is then subtracted from a + b, leaving b. That's why this works. — Robert Harvey, Mar 08 '20 at 15:40
@sepp2k: Assignment expressions return values. That's why `a = b = c = 4;` works. — Robert Harvey, Mar 08 '20 at 15:41
@RobertHarvey If assignment expressions didn't return a value, the code wouldn't compile. That doesn't change that this code invokes UB because it uses and assigns `b` without a sequence point in between. — sepp2k, Mar 08 '20 at 15:50

Petr Skocik · Accepted Answer · 2020-03-08T16:23:56.923

Both result in undefined behavior because you're both accessing and modifying b without an intervening sequence point:

6.5p2:

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.

Here's how you could do it with +/- (UB-free only for unsigned numeric types as signed +/- may result in undefined overflow):

a+=b, b=a-b, a=a-b;

or with xor (always UB-free):

a^=b, b^=a, a^=b;

Gcc and clang appear to recognize both of these patterns and compile them to a swap via a temporary, which is the most efficient method on common architectures: https://gcc.godbolt.org/z/3W_22r

ad absurdum · Answer 2 · 2020-03-08T22:39:03.893

Undefined Behavior in the Posted Code

Both statements lead to undefined behavior, so there should be no expectation that they give the same result.

From the C11 Draft Standard §6.5p2

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.

In the posted code, (b=a) is an expression that evaluates to the value of a, but has the side effect of assigning the value of a to b. In both statements, the value of (b=a) (which is the value of a) is subtracted from b, but here b is a value computation resulting in the value of b. There is no sequence point between these two expressions, which is to say that whether the value computation b is sequenced before or after (b=a) is indeterminate. Since the side effect on b and the value computation of b are unsequenced in both statements, both lead to undefined behavior.

Why Do You Need to Write Code Like This, Anyway?

It is best to avoid "clever" code such as this. In this case the seemingly clever code has undefined behavior; in other cases the clever code may just be difficult to understand for others who must maintain the code, or even for yourself at a later date. Write clear code that is easy to understand and easy to maintain. Only worry about optimizations when you encounter performance issues and have identified the culprit. Compilers are smart, they recognize common idioms, and are able to produce near optimal code for those common idioms when optimizations are turned on. Rarely would you need comma operators or unintuitive XOR swaps; for a simple swap, which is such a common operation in programming, prefer the obvious solution and let your compiler do its job.

The obvious solution, using a temporary variable of the same type as a and b, is easy to understand, can never have undefined behavior (or even implementation-dependent behavior), and will often be optimized by a good compiler to code that is more performant than code coming from well-meaning programmer micro-optimizations:

temp = a;
a = b;
b = temp;

score 0 · Answer 3 · answered Mar 08 '20 at 15:34

0

From C11 standard 6.5.16.2.3

A compound assignment of the form E1 op= E2 is equivalent to the simple assignment expression E1 = E1 op (E2), except that the lvalue E1 is evaluated only once, and with respect to an indeterminately-sequenced function call, the operation of a compound assignment is a single evaluation.

answered Mar 08 '20 at 15:34

Tarek Dakhran

2,021
11
21

In other words, `b=a` returns a. – Robert Harvey Mar 08 '20 at 15:40
5

Isn't this undefined behavior due to sequencing? – S.S. Anne Mar 08 '20 at 15:46
@S.S.Anne that depends of the expression. if E1 is `s` and E2 is s++ it is. id E2 is c++ it is not – 0___________ Mar 08 '20 at 16:25
@P__J__ I meant this specific case. – S.S. Anne Mar 08 '20 at 16:27
The answer commented is general – 0___________ Mar 08 '20 at 16:27
2

What’s written is accurate but not relevant to the problems with the code in the question. – Jonathan Leffler Mar 08 '20 at 17:25
@JonathanLeffler the question was are `a += b` and `a = a + b` different in `C`. In my opinion, the standard answers this question very precisely. – Tarek Dakhran Mar 08 '20 at 19:29
2

Your answer addresses the headline title question — but the code in the body of the question is much less well behaved and needs to be addressed too, which your answer does not. – Jonathan Leffler Mar 08 '20 at 19:36

Are a+=k and a=a+b different in c?

3 Answers3

Undefined Behavior in the Posted Code

Why Do You Need to Write Code Like This, Anyway?