Hello, there is a minor issue when =+ is used by accident instead of +=. It is unfortunate there there is not even a warning, because this is a typo that can cost lots and lots of time. Furthermore it seems that =+ is was the old syntax in the old pre ANSI C. =+ behaves like = (mathematically it is of course the same, but the behavior is still wrong, but there is also never a reason to write =+ instead of =) #include <stdio.h> int main(void) { int a=1,b=1; a += 2; b =+ 2; printf("a=%d b=%d\n",a,b); return 0; } (no warning, not even with -Wall) a=3 b=2 It would be nice if future version could at least throw a warning. Regards Christian Leber
=+ in x =+ y; isn't one token, but two, it is the same as if you write x = + y ; And, unary + is standard C unary operator: The result of the unary + operator is the value of its (promoted) operand. The integer promotions are performed on the operand, and the result has the promoted type. So, I don't think there is anything that should be warned about, it is normal valid C.
There is a lot of normal valid C we warn about...
Yes, "if (b = 2)" is valid and -Wparentheses warns about that. (In reply to comment #0) > It would be nice if future version could at least throw a warning. Obviously it can't be anything *more* than a warning. N.B. at least in C++ there are valid reasons to use the + operator, such as turning an lvalue into an rvalue.
I think we certainly don't want to warn for = +, or =/**/+, so if anything, there could be a warning for = token immediately followed by a token that makes a valid <op>= token (i.e. the same file, same line, column 1 above the = column).
Cross-referencing PR89136 - "libbacktrace/elf.c:2941: suspicious assignment"
making this block the "new-warning" meta-bug
*** Bug 106148 has been marked as a duplicate of this bug. ***