Hi Miguel,
On Thu, Nov 26, 2020 at 3:54 PM Miguel Ojeda
<miguel.ojeda.sandonis@xxxxxxxxx> wrote:
> On Wed, Nov 25, 2020 at 11:44 PM Edward Cree <ecree.xilinx@xxxxxxxxx> 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
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
