linux-kernel - Re: [Outreachy kernel] [PATCH 2/5] staging: rtl8192u: Remove unnecessary else after return

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]

Message-ID: <alpine.DEB.2.20.1702272224290.2127@hadrien>
Date:   Mon, 27 Feb 2017 22:25:23 +0100 (CET)
From:   Julia Lawall <julia.lawall@...6.fr>
To:     simran singhal <singhalsimran0@...il.com>
cc:     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: [Outreachy kernel] [PATCH 2/5] staging: rtl8192u: Remove
 unnecessary else after return



On Mon, 27 Feb 2017, simran singhal wrote:

> This patch fixes the checkpatch warning that else is not generally
> useful after a break or return.
>
> This was done using Coccinelle:
>
> @@
> expression e2;
> statement s1;
> @@
> if(e2) { ... return ...; }
> -else
>          s1
>
> Signed-off-by: simran singhal <singhalsimran0@...il.com>
> ---
>  drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
> index 2453413..4d6c928 100644
> --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
> +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
> @@ -374,8 +374,7 @@ static int ieee80211_tkip_encrypt(struct sk_buff *skb, int hdr_len, void *priv)
>
>  	if (!tcb_desc->bHwSec)
>  		return ret;
> -	else
> -		return 0;
> +	return 0;

In contrast to another patch I commented on, it seems likely that here 0
means success.  Converting 0 to false when that is what it means (ie not
here) makes the code more understandable.

julia