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 20:02:17 +0100	[thread overview]
Message-ID: <527E86B9.2050306@linux.com> (raw)
In-Reply-To: <20131109185741.GW2493@sirena.org.uk>

2013-11-09 19:57 keltezéssel, Mark Brown írta:
> On Sat, Nov 09, 2013 at 04:34:07PM +0100, Levente Kurusa wrote:
>> 2013-11-09 16:16 keltezéssel, Mark Brown írta:
> 
>>>> -	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.
> 
> No, that's not the kernel coding style.
Alright.
> 
>>> 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.
> 
> OK, so that should be in the changelog - or there should be an error
> check for num_regs == 0 which might be more helpful.

Adding an explanation into the changelog and editing the patch
in a way so that it adds a check would be the best choice I think.

Cai, can you please do this as part of the patch?

-- 
Regards,
Levente Kurusa

      reply	other threads:[~2013-11-09 19:02 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
2013-11-09 16:15     ` Greg Kroah-Hartman
2013-11-09 18:57     ` Mark Brown
2013-11-09 19:02       ` Levente Kurusa [this message]

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=527E86B9.2050306@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.