[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <32b0e468-6943-431c-9f71-68fc41727914@kadam.mountain>
Date: Tue, 17 Oct 2023 07:21:13 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Cc: Gilbert Adikankwu <gilbertadikankwu@...il.com>,
Nam Cao <namcao@...utronix.de>, outreachy@...ts.linux.dev,
manishc@...vell.com, GR-Linux-NIC-Dev@...vell.com,
coiby.xu@...il.com, gregkh@...uxfoundation.org,
netdev@...r.kernel.org, linux-staging@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: qlge: Add bool type to qlge_idc_wait()
On Mon, Oct 16, 2023 at 04:19:09PM +0200, Przemek Kitszel wrote:
> On 10/14/23 09:50, Gilbert Adikankwu wrote:
> > On Sat, Oct 14, 2023 at 09:14:23AM +0200, Nam Cao wrote:
> > > On Sat, Oct 14, 2023 at 08:58:13AM +0200, Nam Cao wrote:
> > > > On Sat, Oct 14, 2023 at 07:11:59AM +0100, Gilbert Adikankwu wrote:
> > > > > Reported by checkpatch:
> > > > >
> > > > > WARNING: else is not generally useful after a break or return
> > > > >
> > > >
> > > > What checkpatch is telling you here is that the "else" is redundant and
> > > > can be removed. Although your patch suppresses the warning, it makes the
> > > > code messier :(
> > >
> > > Ah wait, after reading Julia's comment, I realize that the "else" is not
> > > redundant at all. Seems like checkpatch.pl is lying. So ignore what I
> > > said.
> >
> > Thanks
> >
> >
>
> Could you consider fixing checkpatch instead?
Parsing C is quite hard and checkpatch is never going to do it well.
It might be fun to start this project but it's kind of doomed. Doomed
projects can be an educational experience as well.
The way to do it might be to add a new in_else_if variable which tracks
if you are in an else if block. You would look at the indent level and
try the curly braces. Then if the previous thing was an else_if silence
the warning.
But also it's fine that checkpatch prints the occasional incorrect
warning because it teaches people to be more careful.
Another thing is that when you introduce a bug, you should always
consider if other people have done that before as well. Perhaps do
a `git log -p --grep "else is not generally useful"` and see if everyone
else did it correctly and if reviewers caught the mistakes.
regards,
dan carpenter
Powered by blists - more mailing lists