All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.