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:

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:

It is the tmp_buf in the for loop that is the problem.

The ESPIDF I am using apparently uses C++23 with GNU extensions as its language standard. ( https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/cplusplus.html#c-language-standard )

(I am using platformio with the following key platformio.ini settings)

Any advice on how to remedy this so it compiles would be greatly appreciated.
Thanks!

Are you allowed to modify the code?
As the error says, "for increment expression has no effect".
Just remove the tmp_buf part.


Just make sure you actually are incrementing i or breaking somewhere within the for loop's body, else you will have an infinite loop.

PS: On my compiler, this is just a warning, not an error. Perhaps your compiler has restrictive settings enabled. Which is probably for the best.

Ganado,
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?

Thanks again!

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 😏

The code you have posted is valid C/C++ and conforming compilers should accept it (at least with some settings).

GCC does not show a warning by default but it has the warning flag -Wunused-value to enable it.
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wunused-value

This is one of many useful warnings enabled by -Wall. I think most projects enable these warnings.
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wall

Based on your error message it looks like your project is being compiled with -Werror which turns warnings into errors.
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Werror

kigar64551 wrote:
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.

I'm still left wondering why the developer put this variable in as an incrementer in the for loop.

Probably didn't know that you can simply leave the "iteration-expression" of the for statement empty, if it is not needed.
https://en.cppreference.com/w/cpp/language/for

Typically, the loop counter is incremented at that place, so they put the variable there – just without the usual increment operator 😏

(also possible that, once, the variable was incremented there, but after a code change they forgot or didn't care to remove it)

I'm still left wondering why the developer put this variable in as an incrementer in the for loop.

Maybe a bug or a leftover. The direction changed while programming...