lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 1 Mar 2017 00:31:32 +0530
From:   SIMRAN SINGHAL <singhalsimran0@...il.com>
To:     Joe Perches <joe@...ches.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        lustre-devel@...ts.lustre.org, devel@...verdev.osuosl.org,
        linux-kernel@...r.kernel.org, linux-fbdev@...r.kernel.org,
        outreachy-kernel@...glegroups.com
Subject: Re: [PATCH 1/5] staging: lustre: Remove unnecessary else after return

On Tue, Feb 28, 2017 at 2:13 AM, Joe Perches <joe@...ches.com> wrote:
> On Tue, 2017-02-28 at 01:51 +0530, SIMRAN SINGHAL wrote:
>> On Tue, Feb 28, 2017 at 12:55 AM, Joe Perches <joe@...ches.com> wrote:
>> > On Mon, 2017-02-27 at 23:44 +0530, simran singhal wrote:
>> > > This patch fixes the checkpatch warning that else is not generally
>> > > useful after a break or return.
>> >
>> > checkpatch doesn't actually warn for this style
>> >
>> >         if (foo)
>> >                 return bar;
>> >         else
>> >                 return baz;
>> >
>>
>> ok, My bad
>> so, I have to change commit message as checkpatch doesn't warn for this style.
>
> Perhaps better would be to leave them unchanged instead.
>
>> > > diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
> []
>> > > @@ -1806,8 +1806,7 @@ ksocknal_close_matching_conns(struct lnet_process_id id, __u32 ipaddr)
>> > >
>> > >       if (!count)
>> > >               return -ENOENT;
>> > > -     else
>> > > -             return 0;
>> > > +     return 0;
>
> There might be a case for this one.
> error returns are generally in the form
>
> {
>         [...]
>
>         err = func(...);
>         if (err < 0)
>                 return err;
>
>         return 0;
> }
Not sure, what's the problem in removing else as according to me
there is no use of else.

In this case if (if condition) does not satisfy then else condition will
be satisfied and function will return 0.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ