linux-kernel - Re: [PATCH] staging: r8188eu: refactor rtw_is_cckrates{only}

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: <YRv4po3sLcH9VLuo@kroah.com>
Date:   Tue, 17 Aug 2021 19:57:58 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Michael Straube <straube.linux@...il.com>
Cc:     Larry.Finger@...inger.net, phil@...lpotter.co.uk, martin@...ser.cx,
        fmdefrancesco@...il.com, linux-staging@...ts.linux.dev,
        linux-kernel@...r.kernel.org, Joe Perches <joe@...ches.com>
Subject: Re: [PATCH] staging: r8188eu: refactor
 rtw_is_cckrates{only}_included()

On Mon, Aug 16, 2021 at 09:31:25PM +0200, Michael Straube wrote:
> Refactor functions rtw_is_cckrates_included() and
> rtw_is_cckratesonly_included(). Add new helper function rtw_is_cckrate()
> that allows to make the code more compact. Improves readability and
> slightly reduces object file size. Change the return type to bool to
> reflect that the functions return boolean values.
> 
> Suggested-by: Joe Perches <joe@...ches.com>
> Signed-off-by: Michael Straube <straube.linux@...il.com>
> ---
>  drivers/staging/r8188eu/core/rtw_ieee80211.c | 27 +++++++++++---------
>  drivers/staging/r8188eu/include/ieee80211.h  |  5 ++--
>  2 files changed, 17 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/staging/r8188eu/core/rtw_ieee80211.c b/drivers/staging/r8188eu/core/rtw_ieee80211.c
> index 0c7231cefdda..892ffcd92cc7 100644
> --- a/drivers/staging/r8188eu/core/rtw_ieee80211.c
> +++ b/drivers/staging/r8188eu/core/rtw_ieee80211.c
> @@ -68,28 +68,31 @@ int rtw_get_bit_value_from_ieee_value(u8 val)
>  	return 0;
>  }
>  
> -uint	rtw_is_cckrates_included(u8 *rate)
> +static bool rtw_is_cckrate(u8 rate)
>  {
> -	u32	i = 0;
> +	rate &= 0x7f;
> +	return rate == 2 || rate == 4 || rate == 11 || rate == 22;
> +}
> +
> +bool rtw_is_cckrates_included(u8 *rate)
> +{
> +	u8 r;
>  
> -	while (rate[i] != 0) {
> -		if  ((((rate[i]) & 0x7f) == 2) || (((rate[i]) & 0x7f) == 4) ||
> -		     (((rate[i]) & 0x7f) == 11)  || (((rate[i]) & 0x7f) == 22))
> +	while ((r = *rate++)) {
> +		if (rtw_is_cckrate(r))
>  			return true;
> -		i++;
>  	}
> +
>  	return false;
>  }
>  
> -uint	rtw_is_cckratesonly_included(u8 *rate)
> +bool rtw_is_cckratesonly_included(u8 *rate)
>  {
> -	u32 i = 0;
> +	u8 r;
>  
> -	while (rate[i] != 0) {
> -		if  ((((rate[i]) & 0x7f) != 2) && (((rate[i]) & 0x7f) != 4) &&
> -		     (((rate[i]) & 0x7f) != 11)  && (((rate[i]) & 0x7f) != 22))
> +	while ((r = *rate++)) {

Ick, no.

While it might be fun to play with pointers like this, trying to
determine the precidence issues involved with reading from, and then
incrementing the pointer like this is crazy.

The original was obvious as to how it was walking through the array.
Keep that here.

Remember, we write code for humans first, compliers second.

thanks,

greg k-h