Hi Miguel,
On Thu, Nov 26, 2020 at 3:54 PM Miguel Ojeda miguel.ojeda.sandonis@gmail.com wrote:
On Wed, Nov 25, 2020 at 11:44 PM Edward Cree ecree.xilinx@gmail.com wrote:
To make the intent clear, you have to first be certain that you understand the intent; otherwise by adding either a break or a fallthrough to suppress the warning you are just destroying the information that "the intent of this code is unknown".
If you don't know what the intent of your own code is, then you *already* have a problem in your hands.
The maintainer is not necessarily the owner/author of the code, and thus may not know the intent of the code.
or does it flag up code that can be mindlessly "fixed" (in which case the warning is worthless)? Proponents in this thread seem to be trying to have it both ways.
A warning is not worthless just because you can mindlessly fix it. There are many counterexamples, e.g. many checkpatch/lint/lang-format/indentation warnings, functional ones like the `if (a = b)` warning...
BTW, you cannot mindlessly fix the latter, as you cannot know if "(a == b)" or "((a = b))" was intended, without understanding the code (and the (possibly unavailable) data sheet, and the hardware, ...).
P.S. So far I've stayed out of this thread, as I like it if the compiler flags possible mistakes. After all I was the one fixing new "may be used uninitialized" warnings thrown up by gcc-4.1, until (a bit later than) support for that compiler was removed...
Gr{oetje,eeting}s,
Geert