From: Dan Carpenter <dan.carpenter@oracle.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 11/14] ARM: brcmstb: delete unneeded test before of_node_put
Date: Wed, 27 Aug 2014 10:13:53 +0000 [thread overview]
Message-ID: <20140827101353.GG5046@mwanda> (raw)
In-Reply-To: <20140814065310.GK11952@brian-ubuntu>
On Wed, Aug 13, 2014 at 11:53:10PM -0700, Brian Norris wrote:
> > > > cleanup:
> > > > - if (syscon_np)
> > > > - of_node_put(syscon_np);
> > > > -
> > > > + of_node_put(syscon_np);
> > > > +out:
> > >
> > > Is there a good reason for this new label? I thought part of the point
> > > of this semantic patch is that the previous line (of_node_put()) is a
> > > no-op for NULL arguments.
> >
> > Personally, I prefer code to only be executed if it needs to be. It is
> > helpful from a program analysis point of view, and I think it helps
> > someone trying to understand the code.
> >
> > That is, when I am trying to understand some unknown code, I may look at
> > the cleanup code and try to figure out why each piece of it is executed.
> > If some of it is statically known to be irrelevant, it is confusing.
> >
> > But I you think the other way around, and would rather have just one label
> > that contains anything that might ever be useful, then I guess that is a
> > reasonable point of view as well.
>
> Yeah, I personally just look to avoid unnecessary labels.
>
Having more than one label is better because it helps you avoid "One Err
Bugs". This is a common kind of bug which is cause when functions have
only one "err:" label which does all the error handling.
Some examples of this type of bug are:
234ad18249a4 ('staging: gdm7240: fix error handling of probe()')
85a258b70d48 ('ocfs2: fix error handling in ocfs2_ioctl_move_extents()')
920c4f4c3651 ('drivers/leds/leds-tca6507.c: cleanup error handling in tca6507_probe()')
If you unwind in the exact reversed order of how things were allocated
then it makes the code a lot easier to understand so it avoids bugs.
regards,
dan carpenter
WARNING: multiple messages have this Message-ID (diff)
From: dan.carpenter@oracle.com (Dan Carpenter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 11/14] ARM: brcmstb: delete unneeded test before of_node_put
Date: Wed, 27 Aug 2014 13:13:53 +0300 [thread overview]
Message-ID: <20140827101353.GG5046@mwanda> (raw)
In-Reply-To: <20140814065310.GK11952@brian-ubuntu>
On Wed, Aug 13, 2014 at 11:53:10PM -0700, Brian Norris wrote:
> > > > cleanup:
> > > > - if (syscon_np)
> > > > - of_node_put(syscon_np);
> > > > -
> > > > + of_node_put(syscon_np);
> > > > +out:
> > >
> > > Is there a good reason for this new label? I thought part of the point
> > > of this semantic patch is that the previous line (of_node_put()) is a
> > > no-op for NULL arguments.
> >
> > Personally, I prefer code to only be executed if it needs to be. It is
> > helpful from a program analysis point of view, and I think it helps
> > someone trying to understand the code.
> >
> > That is, when I am trying to understand some unknown code, I may look at
> > the cleanup code and try to figure out why each piece of it is executed.
> > If some of it is statically known to be irrelevant, it is confusing.
> >
> > But I you think the other way around, and would rather have just one label
> > that contains anything that might ever be useful, then I guess that is a
> > reasonable point of view as well.
>
> Yeah, I personally just look to avoid unnecessary labels.
>
Having more than one label is better because it helps you avoid "One Err
Bugs". This is a common kind of bug which is cause when functions have
only one "err:" label which does all the error handling.
Some examples of this type of bug are:
234ad18249a4 ('staging: gdm7240: fix error handling of probe()')
85a258b70d48 ('ocfs2: fix error handling in ocfs2_ioctl_move_extents()')
920c4f4c3651 ('drivers/leds/leds-tca6507.c: cleanup error handling in tca6507_probe()')
If you unwind in the exact reversed order of how things were allocated
then it makes the code a lot easier to understand so it avoids bugs.
regards,
dan carpenter
WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: "Julia Lawall" <julia.lawall@lip6.fr>,
"Marc Carino" <marc.ceeeee@gmail.com>,
kernel-janitors@vger.kernel.org,
"Christian Daudt" <bcm@fixthebug.org>,
"Matt Porter" <mporter@linaro.org>,
"Russell King" <linux@arm.linux.org.uk>,
linux-arm-kernel@lists.infradead.org,
bcm-kernel-feedback-list@broadcom.com,
linux-kernel@vger.kernel.org,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Subject: Re: [PATCH 11/14] ARM: brcmstb: delete unneeded test before of_node_put
Date: Wed, 27 Aug 2014 13:13:53 +0300 [thread overview]
Message-ID: <20140827101353.GG5046@mwanda> (raw)
In-Reply-To: <20140814065310.GK11952@brian-ubuntu>
On Wed, Aug 13, 2014 at 11:53:10PM -0700, Brian Norris wrote:
> > > > cleanup:
> > > > - if (syscon_np)
> > > > - of_node_put(syscon_np);
> > > > -
> > > > + of_node_put(syscon_np);
> > > > +out:
> > >
> > > Is there a good reason for this new label? I thought part of the point
> > > of this semantic patch is that the previous line (of_node_put()) is a
> > > no-op for NULL arguments.
> >
> > Personally, I prefer code to only be executed if it needs to be. It is
> > helpful from a program analysis point of view, and I think it helps
> > someone trying to understand the code.
> >
> > That is, when I am trying to understand some unknown code, I may look at
> > the cleanup code and try to figure out why each piece of it is executed.
> > If some of it is statically known to be irrelevant, it is confusing.
> >
> > But I you think the other way around, and would rather have just one label
> > that contains anything that might ever be useful, then I guess that is a
> > reasonable point of view as well.
>
> Yeah, I personally just look to avoid unnecessary labels.
>
Having more than one label is better because it helps you avoid "One Err
Bugs". This is a common kind of bug which is cause when functions have
only one "err:" label which does all the error handling.
Some examples of this type of bug are:
234ad18249a4 ('staging: gdm7240: fix error handling of probe()')
85a258b70d48 ('ocfs2: fix error handling in ocfs2_ioctl_move_extents()')
920c4f4c3651 ('drivers/leds/leds-tca6507.c: cleanup error handling in tca6507_probe()')
If you unwind in the exact reversed order of how things were allocated
then it makes the code a lot easier to understand so it avoids bugs.
regards,
dan carpenter
next prev parent reply other threads:[~2014-08-27 10:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-08 10:07 [PATCH 11/14] ARM: brcmstb: delete unneeded test before of_node_put Julia Lawall
2014-08-08 10:07 ` Julia Lawall
2014-08-08 10:07 ` Julia Lawall
2014-08-13 22:22 ` Brian Norris
2014-08-13 22:22 ` Brian Norris
2014-08-13 22:22 ` Brian Norris
2014-08-14 5:37 ` Julia Lawall
2014-08-14 5:37 ` Julia Lawall
2014-08-14 5:37 ` Julia Lawall
2014-08-14 6:53 ` Brian Norris
2014-08-14 6:53 ` Brian Norris
2014-08-14 6:53 ` Brian Norris
2014-08-27 10:13 ` Dan Carpenter [this message]
2014-08-27 10:13 ` Dan Carpenter
2014-08-27 10:13 ` Dan Carpenter
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=20140827101353.GG5046@mwanda \
--to=dan.carpenter@oracle.com \
--cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.