In FreeRTOS V10.0.1 the function xQueueGenericSend() has a possible execution path where no return value is returned to the caller. If in line 879 the condition
is true, then there will be no value returned.
I try to always compile with -pedantic activated (Gnu Compiler) and the function xQueueGenericSend() generates ther following warning:
No return, in function returning non-void
That code is inside a for(ever) loop, so the only way it can break out
of the loop and return would be for there to be a break or return
statement - which there isn’t (at least, not without a return value), so
I cannot see a path that could result in a return without a value.
Unless that is, the high optimisation level you have has re-arranged the
code in a way that is not representative of the original code, which
could potentially be due to a pedantic interpretation of ‘implementation
defined’ behavior in C.
Yes, the very end of the function does not have a return, but the end of the function is preceeded by a for(; loop (loop forever) which does not have any breaks within it. Therefore the end of the function can never be reached. This is totally allowed by the C Standard, and the warning is likely that the optimization level is too low for gcc to realize that you can’t reach the end of the function.
You could put a (dummy) return statement there, but then you will get a warning about unreachable code when you turn up to opimization level.
I suppose one option would be to change one of the returns to a break (to get out of the loop) and add that return at the end of the function just to make it so you CAN reach the end, but that is sort of obfuscating the code to silence a false warning.
As you mentioned, I also dislike changing the code just to silence this warning.
The hint of Richard Barry regarding the compiler optimization forced me to look deeper, because I use two different settings for this: -Os for Release build and -Og for debug build.
But the warning was always the same. So there must be something else going on.
Long story short, it wasn’t a compiler generated warning.
I use Eclipse as programming environment and it turns out that the eclipse internal static code analysis flagged this piece of code with this warning.
Now I disabled this “feature”.
Sorry for the noise. But maybe this thread can help someone who stumbles about the same problem with static code analysis, which doesn’t seem to be that smart.
Ok,so the ‘compiler’ that wasn’t optimizing enough to see the exit wasn’t used was actually the IDE.
I also agree that this doesn’t seem to be something worth modifying code to be less clear just to silence the warning (since it requires a structual change to really silence the warning).
Ha, you will be amazed at how many support requests for ‘compiler’
warnings turn out to be Eclipse only pretending to know how to parse C
code. I always turn that pretendy parsing off. :o)
Eclipse is usually reasonably smart in its checking of C code, but it is not as sophisticated as gcc. I find it convenient for spotting typos as fast as possible. The details vary considerably from version to version of Eclipse.
One possibility that might work without being an incorrect code change (adding a return statement that is never reached is, I would say, incorrect coding - or at least confusing) is to use gcc’s “builtin_unreachable()” function. This tells the compiler “control flow will never reach this point” and can be useful for optimisation, and static analysis as well as documenting to humans that, in this case, the “missing” return is intentional.
Of course, you’d want to have this as a macro that can be changed to suit different compilers.
loop (loop forever) which does not have any breaks within it. Therefore the end of the function can never be reached. This is totally allowed by the C Standard, and the warning is likely that the optimization level is too low for gcc to realize that you can’t reach the end of the function.