I am in the process of moving some code to a new toolchain and encountered the following code (which is running in many production systems just fine) that will not compile and throws the following error:
for increment expression has no effect [-Werror=unused-value]
I am not familiar with using an array as an incrementor in a for loop and could not figure out a way to google for this. Here is the minimal code:
1 2 3
for (uint32_t i = 0; i < http.total_len; tmp_buf)
It is the tmp_buf in the for loop that is the problem.
Thanks. You make a good point in that I can see that i is in fact incremented in the code. It appears to be incremented by the number of bytes read during each pass. So, I will try it without the third field in the for. Odd that it compiles without any warnings at all when using just framework = arduino (but that does not give me some other functionality that I need).
Do you know what C version you are compiling under?
C allows a lot of weird things, such as writing down a variable name without any operation – which effectively compiles to a NOP. That is probably for reasons of backwards-compatibility. Remember that C was created in the late 1960's and didn't have a proper standard until 1989. Anyways, C compilers have a lot of options to control warnings, or even turn warnings into errors. What will be treated as a warning (by default) can change over time, in different compiler versions. Let alone different compilers (e.g. MVSC vs. GCC vs. Clang).
If you ever wrote code that is supposed to run on different platforms and that is supposed to be compiled with different C compilers, you will notice that every compiler and/or platform tends to bring up other warnings. Sometimes they can't agree on what they like/dislike 🙄
Still, I think it's best to choose the highest warning level and even enable the "treat warnings as errors" option. Then inspect/fix every single warning or, where it can't be fixed reasonably, add an exception for that specific warning at the specific place. This can be a lot of work, if the code was maintained badly before, but you will have so much cleaner code afterwards. And it can really safe your arse 😏
If you ever wrote code that is supposed to run on different platforms and that is supposed to be compiled with different C compilers, you will notice that every compiler and/or platform tends to bring up other warnings.
This is why it might not be such a good idea to turn warnings into errors by default if you have a build script that is supposed to be used by many different people with different compilers/compiler versions.
Even if the warning flags are named the same they might not work exactly the same between different compilers, or between different versions of the same compiler. Sometimes the warnings that you get can be affected by the optimization flags that are being used because lower optimization levels don't analyse the code enough to detect a problem.
The person building the program might not be a developer on the team and might lack the skills to be able to correct the code if he gets an error. A warning on the other hand is usually not a problem because it can easily be ignored (real problematic warnings have hopefully already been sorted out before the release).
That doesn't mean you shouldn't turn warnings into errors yourself while working on the project if that is what you prefer.
I'm still left wondering why the developer put this variable in as an incrementer in the for loop. I wrote to the company and will see if they take the time to look at it and reply.
The compiler settings are unclear to me because I get several warnings from code that is other people's libraries but only this one was flagged as an error and kept things from progressing to the linker.