From: Levente Kurusa <levex@linux.com>
To: Mark Brown <broonie@kernel.org>, Caizhiyong <caizhiyong@hisilicon.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Wanglin (Albert)" <albert.wanglin@hisilicon.com>
Subject: Re: [PATCH] regmap: Fix compile warning with value uninitialized
Date: Sat, 09 Nov 2013 16:34:07 +0100 [thread overview]
Message-ID: <527E55EF.5080504@linux.com> (raw)
In-Reply-To: <20131109151626.GT2493@sirena.org.uk>
2013-11-09 16:16 keltezéssel, Mark Brown írta:
> On Sat, Nov 09, 2013 at 09:49:11AM +0000, Caizhiyong wrote:
>
>> @@ -2170,7 +2170,8 @@ int regmap_register_patch(struct regmap *map, const struct reg_default *regs,
>> int num_regs)
>> {
>> struct reg_default *p;
>> - int i, ret;
>> + int i;
>> + int ret = 0;
>> bool bypass;
Wouldn't the following be better?
int i, ret = 0;
I think it is more readable.
>
> This sort of fix isn't ideal, it just silences the warning but if the
> compiler has spotted a genuine oversight in the function it won't
> address it. It's better to include some analysis of why this is a good
> fix.
>
The only condition when 'ret' is not set is when the num_regs parameter is zero
and krealloc doesn't fail. If the above two conditions apply, then
the code would return an uninitialized value. However, calling this function with
num_regs == 0, would be a waste as it essentially does nothing.
Also, I think code which throws warnings is worse than code
which doesn't.
--
Regards,
Levente Kurusa
next prev parent reply other threads:[~2013-11-09 15:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-09 9:49 [PATCH] regmap: Fix compile warning with value uninitialized Caizhiyong
2013-11-09 15:16 ` Mark Brown
2013-11-09 15:34 ` Levente Kurusa [this message]
2013-11-09 16:15 ` Greg Kroah-Hartman
2013-11-09 18:57 ` Mark Brown
2013-11-09 19:02 ` Levente Kurusa
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=527E55EF.5080504@linux.com \
--to=levex@linux.com \
--cc=albert.wanglin@hisilicon.com \
--cc=broonie@kernel.org \
--cc=caizhiyong@hisilicon.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.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.