public inbox for kernel-janitors@vger.kernel.org
 help / color / mirror / Atom feed
From: Shannon Nelson <shannon.nelson@oracle.com>
To: kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] sparc: vDSO: Silence an uninitialized variable warning
Date: Sun, 14 Oct 2018 22:44:02 +0000	[thread overview]
Message-ID: <d5005b5d-e263-c394-5d13-ef1306cda352@oracle.com> (raw)
In-Reply-To: <20181013102653.GE16086@mwanda>

On 10/14/2018 12:52 AM, Dan Carpenter wrote:
> On Sat, Oct 13, 2018 at 11:18:20AM -0700, Shannon Nelson wrote:
>> On 10/13/2018 3:26 AM, Dan Carpenter wrote:
>>> Smatch complains that "val" would be uninitialized if kstrtoul() fails.
>>>
>>> Fixes: 9a08862a5d2e ("vDSO for sparc")
>>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>> ---
>>>    arch/sparc/vdso/vma.c | 4 +++-
>>>    1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/sparc/vdso/vma.c b/arch/sparc/vdso/vma.c
>>> index f51595f861b8..5eaff3c1aa0c 100644
>>> --- a/arch/sparc/vdso/vma.c
>>> +++ b/arch/sparc/vdso/vma.c
>>> @@ -262,7 +262,9 @@ static __init int vdso_setup(char *s)
>>>    	unsigned long val;
>>>    	err = kstrtoul(s, 10, &val);
>>> +	if (err)
>>> +		return err;
>>>    	vdso_enabled = val;
>>> -	return err;
>>> +	return 0;
>>>    }
>>>    __setup("vdso=", vdso_setup);
>>>
>>
>> This is probably fine, but it might be cleaner as
>>
>>     	err = kstrtoul(s, 10, &val);
>> 	if (!err)
>> 		vdso_enabled = val;
>> 	return err;
> 
> I always tell people to do failure handling instead of success handling.
> And also I tell people not to make the last if statement in a function
> a special case.  Like you see this a lot right:
> 
> 	ret = frob();
> 	if (ret)
> 		return ret;
> 
> 	ret = frob();
> 	if (ret)
> 		return ret;
> 
> 	ret = frob();
> 	if (!ret)
> 		*p = whatever;
> 	return ret;
> 
> If you do failure handling then the success path is at indent level one
> and failure handling is two tabs.  But if you mix it up it's not as
> clear.  I have never studied this, but my impression from looking at
> static analysis over the years is that success handling is error prone.
> 
> regards,
> dan carpenter
> 

(driving right into the bikeshed...)

Yes, and that's the way I would normally go, especially if there was 
more to that little function.  But in this case with such a short little 
function, I hate seeing it messed up with unnecessary lines.

Anyway, enough with the noise, either way is fine.

sln

  parent reply	other threads:[~2018-10-14 22:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-13 10:26 [PATCH] sparc: vDSO: Silence an uninitialized variable warning Dan Carpenter
2018-10-13 18:18 ` Shannon Nelson
2018-10-14  7:52 ` Dan Carpenter
2018-10-14 22:44 ` Shannon Nelson [this message]
2018-10-18  4:55 ` David Miller

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=d5005b5d-e263-c394-5d13-ef1306cda352@oracle.com \
    --to=shannon.nelson@oracle.com \
    --cc=kernel-janitors@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox