From: Cong Ding <dinggnu@gmail.com>
To: "Hans J. Koch" <hjk@hansjkoch.de>
Cc: Vitalii Demianets <vitas@nppfactor.kiev.ua>,
linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] uio.c: Fix warning: 'ret' might be used uninitialized
Date: Sat, 1 Dec 2012 09:58:32 +0000 [thread overview]
Message-ID: <20121201095831.GA18966@gmail.com> (raw)
In-Reply-To: <20121201035625.GC2603@local>
On Sat, Dec 01, 2012 at 04:56:25AM +0100, Hans J. Koch wrote:
> On Sat, Dec 01, 2012 at 02:22:44AM +0100, Cong Ding wrote:
> > On Fri, Nov 30, 2012 at 10:33 PM, Hans J. Koch <hjk@hansjkoch.de> wrote:
> > > On Fri, Nov 30, 2012 at 12:12:46PM +0100, Tux9 wrote:
> > >> I like Vitalii's solution more. Hans's solution assign the value
> > >> -ENOMEM to ret in every round of the loop, which is a kind of wasting
> > >> CPU cycles.
> > >
> > > The difference between
> > > 1 files changed, 12 insertions(+), 4 deletions(-) and
> > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > >
> > > is more important. Note that this code is not in a fast path but only
> > > called once at device creation.
> > Why do you think the size of the patch is so important? I think the
> > most important thing is the coding style and efficiency. I agree
> > efficiency is not important in this case, but what about coding style?
>
> Most important. Short is beautiful.
>
> > Your code is _not_ very easy to understand.
>
> You think so?
>
> > It's a very natural thing
> > to set the return value and then goto the error-handling codes, which
> > is exactly same as what Vitalii did, rather than setting an initial
> > value in the beginning of each round of the loop as you did.
>
> Setting a default value at the beginning of a block is the most natural
> thing. I don't want to repeat the same code in three places.
>
> > There are
> > also a bunch of codes in kernel in the same style with Vitalii, but I
> > cannot find anything same as your codes.
>
> If you follow LKML closely, you'll notice that simplifying code by
> replacing unnecessary repetitions with shorter versions is always welcome.
> If we didn't go for that, the kernel source would be a few million lines
> bigger by now.
>
> Thanks,
> Hans
If it is really necessary to save the 4 lines of codes, I would suggest to do
in the following style. But you are more senior than me, so I may be wrong in
this aspect.
drivers/uio/uio.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 5110f36..cb20168 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -263,7 +263,7 @@ static struct class uio_class = {
*/
static int uio_dev_add_attributes(struct uio_device *idev)
{
- int ret;
+ int ret = 0;
int mi, pi;
int map_found = 0;
int portio_found = 0;
@@ -339,6 +339,8 @@ err_map:
kobject_put(&map->kobj);
}
kobject_put(idev->map_dir);
+ if (!ret)
+ ret = -ENOMEM;
dev_err(idev->dev, "error creating sysfs files (%d)\n", ret);
return ret;
}
next prev parent reply other threads:[~2012-12-01 9:58 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-27 11:48 [PATCH] uio.c: Fix warning: 'ret' might be used uninitialized Vitalii Demianets
2012-11-27 12:24 ` Vitalii Demianets
2012-11-27 22:43 ` Hans J. Koch
2012-11-28 8:58 ` Vitalii Demianets
2012-11-28 21:05 ` Hans J. Koch
2012-11-29 16:05 ` Tux9
2012-11-29 16:22 ` Vitalii Demianets
2012-11-29 16:33 ` Cong Ding
2012-11-29 16:36 ` Vitalii Demianets
2012-11-29 23:58 ` Hans J. Koch
2012-11-30 11:12 ` Tux9
2012-11-30 21:33 ` Hans J. Koch
2012-12-01 1:22 ` Cong Ding
2012-12-01 3:56 ` Hans J. Koch
2012-12-01 9:58 ` Cong Ding [this message]
2012-12-03 7:51 ` Hans J. Koch
2012-11-30 11:16 ` Vitalii Demianets
2012-11-30 21:39 ` Hans J. Koch
2012-11-30 23:43 ` Greg Kroah-Hartman
2012-12-03 7:41 ` [PATCH] stable: uio: " Hans J. Koch
2012-12-03 13:38 ` Ben Hutchings
2012-12-03 8:35 ` [PATCH] uio.c: " Vitalii Demianets
2012-12-03 8:53 ` Vitalii Demianets
2012-12-03 17:27 ` Hans J. Koch
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=20121201095831.GA18966@gmail.com \
--to=dinggnu@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hjk@hansjkoch.de \
--cc=linux-kernel@vger.kernel.org \
--cc=vitas@nppfactor.kiev.ua \
/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).