4

For an example:

#include <stdio.h>
#define TS_SIZE 188

int main(void)
{
    volatile int offset = 0;
    volatile int len = 10;

    for (int i=0; i < len; i++)
    {
        offset =+ TS_SIZE; /* This should be += */
    }
    
    printf("Offset: %d \n", offset);
    return 0;
}

Tried "-Wall, -Wextra and, -pedantic", not luck even with latest GCC (10.x) on godbolt compiler explorer.

Note: This is just a small contrived example code. Volatile's used for obvious reasons.

Lundin
  • 195,001
  • 40
  • 254
  • 396
the kamilz
  • 1,860
  • 1
  • 15
  • 19
  • "Volatile's used for obvious reasons." - you don't actually need it. It doesn't matter for the example if GCC optimizes the loop away. – user2357112 Feb 23 '21 at 12:34
  • 1
    I don't know of anything in GCC that can do that, but you can easily write a small script that looks for instances of `=+` and warn in that case: "did you mean += ?" – Morten Jensen Feb 23 '21 at 12:35
  • 2
    why would you want GCC to warn a totally valid code? in that case use grep! – thakee nathees Feb 23 '21 at 12:36
  • 4
    I believe `if (a = b)` is also valid code, but... – the kamilz Feb 23 '21 at 12:38
  • 5
    @thakeenathees: Plenty of warnings are for valid code. For invalid code, we want an error. Warnings are for "this is technically allowed but you probably made a mistake there". – user2357112 Feb 23 '21 at 12:39
  • 2
    These kind of bugs are an initiation rite for C programmers. You keep writing them over and over until you learn to spot them in your sleep. – Lundin Feb 23 '21 at 12:40
  • @user2357112supportsMonica No that's wrong. In case of gcc, which is a lax compiler, warnings means "this is wrong, this is a bug, but I'm gonna generate a binary executable anyway." You need to compile with `-std=c17 -pedantic-errors` if you want errors for invalid code. – Lundin Feb 23 '21 at 12:43
  • 2
    @thekamilz: Warnings are often for “valid” code. Errors are, by default, for “We cannot make this work”; warnings are “We can make this work, but it may not do what you intended.” Warnings are for catching things that are often mistakes even though they resulted in code that can be compiled. They can be recognized by patterns of human behavior even where they are valid C code. For example, `if (a = b) …` is often a mistake; often the actual intent was `if (a == b) …`. So it is useful to have the compiler warn about this, and people who actually intend `=` can use `if ((a = b)) …` to denote it. – Eric Postpischil Feb 23 '21 at 12:50
  • 5
    Trivia alert: Once upon a very long time ago (I'm talking 1970s), `=+` was the right way to write it, but there were parsing ambiguities, so it was changed to `+=`. But for a while the compilers accepted `=+` for backwards compatibility, and they *did* warn about it, which would have been just what the kamilz wants now. – Steve Summit Feb 23 '21 at 13:02
  • 1
    @SteveSummit Yikes, really? I just opened the dusty old K&R 1st edition from 1978 and even that one got `+=`. – Lundin Feb 23 '21 at 15:20
  • 1
    @Lundin Others have noted the history of the `=+` operator. See https://stackoverflow.com/questions/41616477/what-is-the-difference-between-and-c-assignment-operators and especially https://stackoverflow.com/questions/7573978/what-does-mean-in-c – Andrew Henle Feb 23 '21 at 15:44
  • 2
    @SteveSummit You're right it seems. In the [2nd ed book](https://www.edutechlearners.com/download/books/The%20C%20Programming%20Language%20by%20Kernighan%20&%20Ritchie%20PDF.pdf) it is said "*The old assignment operators like =+ are truly gone*" ... – Déjà vu Feb 23 '21 at 15:45
  • 4
    Clang does warn, though: "warning: use of unary operator that may be intended as compound assignment" – ilkkachu Feb 23 '21 at 16:06

2 Answers2

1

It's not really the compiler's job. A compiler is there to check if your code is valid C and then translate your source code into machine code for the target system.

However, compilers have become increasingly friendly over the years and sometimes warn against common bugs, poorly-defined behavior or other potential run-time misbehavior. This friendliness shouldn't be mistaken for some guarantee that the compiler will catch all such bugs though.

While compilers tend to warn for if(a = b), gcc with max warnings doesn't even warn for something obvious such as int arr[2]; arr[2]=1; (clang and icc does). And as you noticed, not for =+, =! etc either.

The solution for this is to have a software quality system that covers as many known issues as possible. Not just relying on compiler warnings alone, but taking the step to become a professional software engineer. That means coding style guides, coding standards for using a safe subset of C, static analysis tools, code "beautifiers" and peer code reviews.

Static analysers can find a lot of bugs that the compiler doesn't look for, but perhaps not this particular bug unless you explicitly configure it to look for it. A coding standard + code beautifier ought to transform the code into offset = +TS_SIZE; though, after which manual code review will easily spot the bug.


EDIT: as pointed out in comments, =+ was once valid C in very early pre-K&R versions. Some history lessons here: What does =+ mean in C?, see the great answer by Jonathan Leffler in particular.

Lundin
  • 195,001
  • 40
  • 254
  • 396
-4

Good morning ! I believe there is no option in GCC that can do this... because there is no need for that kind of thing ! "=+" is an operator in the C language, the compiler can't give you an error or a warning for something that works very well. You can read explanations about the difference between "+=" and "=+" here in StackOverflow. Good luck !

Elias
  • 13
  • 2
  • (a) `=+` is not an operator in standard C. The *punctuator* tokens from which `+=`, but not `=+` arises as an operator are listed in C 2018 6.4.6 1. (b) The compiler can give you warnings for code that has behavior fully defined by the C standard. C 2018 Note 9 says “Of course, an implementation is free to produce any number of diagnostic messages, often referred to as warnings, as long as a valid program is still correctly translated.” Annex I lists warnings that are commonly generated by C implementations even though none are otherwise specified as part of the standard. – Eric Postpischil Feb 23 '21 at 14:14