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
next prev 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