From: Geert Uytterhoeven <geert@linux-m68k.org>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
Date: Thu, 26 Nov 2020 16:28:12 +0100 [thread overview]
Message-ID: <CAMuHMdV5kOakvZJMWLxbpigFPS+Xuw6DVYsWCWZy7wGsv3idcw@mail.gmail.com> (raw)
In-Reply-To: <CANiq72nobq=ptWK-qWxU91JHqkKhMcRtJNnw2XJd5-vSJWZd8Q@mail.gmail.com>
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
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
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
next prev parent reply other threads:[~2020-11-26 15:28 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-20 18:21 [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang Gustavo A. R. Silva
2020-11-20 18:25 ` [Cluster-devel] [PATCH 006/141] gfs2: " Gustavo A. R. Silva
2021-04-20 20:29 ` Gustavo A. R. Silva
2021-04-20 20:40 ` Andreas Grünbacher
2020-11-20 18:28 ` [Cluster-devel] [PATCH 000/141] " Joe Perches
2020-11-20 19:02 ` Gustavo A. R. Silva
2020-11-20 18:53 ` Jakub Kicinski
2020-11-20 19:04 ` Gustavo A. R. Silva
2020-11-20 19:30 ` Kees Cook
2020-11-20 19:51 ` Jakub Kicinski
2020-11-20 20:48 ` Kees Cook
2020-11-22 16:17 ` Kees Cook
2020-11-22 18:21 ` James Bottomley
2020-11-22 18:25 ` Joe Perches
2020-11-22 19:12 ` James Bottomley
2020-11-22 19:22 ` Joe Perches
2020-11-22 19:53 ` James Bottomley
2020-11-23 13:03 ` [Cluster-devel] [Intel-wired-lan] " Gustavo A. R. Silva
2020-11-23 16:31 ` James Bottomley
2020-11-24 21:32 ` Kees Cook
2020-11-24 22:24 ` Finn Thain
2020-11-24 23:15 ` Miguel Ojeda
2020-11-24 23:53 ` Finn Thain
2020-11-25 1:05 ` Miguel Ojeda
2020-11-25 7:05 ` James Bottomley
2020-11-25 12:24 ` Nick Desaulniers
2020-11-25 16:24 ` Jakub Kicinski
2020-11-25 17:04 ` Miguel Ojeda
2020-11-25 22:09 ` Nick Desaulniers
2020-11-25 21:33 ` Finn Thain
2020-11-25 22:09 ` Nick Desaulniers
2020-11-25 23:21 ` Finn Thain
2020-11-26 0:30 ` Finn Thain
2020-11-25 21:10 ` Kees Cook
2020-11-22 20:35 ` [Cluster-devel] " Miguel Ojeda
2020-11-22 22:36 ` James Bottomley
2020-11-23 14:19 ` Miguel Ojeda
2020-11-23 15:58 ` James Bottomley
2020-11-23 16:24 ` Rafael J. Wysocki
2020-11-23 16:32 ` Joe Perches
2020-11-23 18:56 ` Miguel Ojeda
2020-11-23 20:37 ` James Bottomley
2020-11-25 0:32 ` Miguel Ojeda
2020-11-25 22:44 ` Edward Cree
2020-11-26 14:53 ` Miguel Ojeda
2020-11-26 15:28 ` Geert Uytterhoeven [this message]
2020-11-26 16:18 ` Karol Herbst
2020-11-26 17:05 ` Miguel Ojeda
2020-11-25 10:38 ` Andy Shevchenko
2020-11-25 9:01 ` Sean Young
2020-11-22 22:54 ` Finn Thain
2020-11-22 23:04 ` James Bottomley
2020-11-23 14:05 ` Miguel Ojeda
2020-11-24 0:58 ` Finn Thain
2020-11-24 1:05 ` Joe Perches
2020-11-24 2:48 ` Finn Thain
2020-11-24 23:46 ` Miguel Ojeda
2020-11-22 22:10 ` Sam Ravnborg
2020-11-24 1:32 ` Nick Desaulniers
2020-11-24 1:46 ` Jakub Kicinski
2020-11-24 21:25 ` Kees Cook
2020-11-25 23:02 ` Edward Cree
2020-12-01 14:08 ` Dan Carpenter
2020-12-01 14:04 ` Dan Carpenter
2020-11-20 22:21 ` Miguel Ojeda
2020-11-23 20:03 ` Jason Gunthorpe
2020-11-24 14:47 ` Gustavo A. R. Silva
2020-11-23 20:38 ` Mark Brown
2020-11-24 14:47 ` Gustavo A. R. Silva
2020-12-01 5:52 ` Martin K. Petersen
2020-12-01 8:20 ` Gustavo A. R. Silva
2020-12-08 4:52 ` [Cluster-devel] (subset) " Martin K. Petersen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMuHMdV5kOakvZJMWLxbpigFPS+Xuw6DVYsWCWZy7wGsv3idcw@mail.gmail.com \
--to=geert@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).