A few redundant switch cases as well as a redundant if/else
within one of the cases was consolidated to a single call.
The cases are intentionally retained for documentation purposes.
Signed-off-by: Nicholas Mc Guire <[email protected]>
---
case WIFI_REASSOCREQ,WIFI_PROBEREQ,WIFI_BEACON,WIFI_ACTION all
have the same effect - notably the also for WIFI_PROBEREQ where
the if/else is executing the same function.
These redundant cases could all be dropped and consolidated into
the default but probably it is better for documentation/readability
to leave them in the switch/case explicitly.
Patch was only compile-tested for x86_64_defconfig + CONFIG_STAGING=y
CONFIG_R8188EU=m
Patch is against 3.19.0-rc7 (localversion-next is -next-20150204)
drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index 28918201..cd12dd7 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -484,17 +484,8 @@ void mgt_dispatcher(struct adapter *padapter, struct recv_frame *precv_frame)
/* fall through */
case WIFI_ASSOCREQ:
case WIFI_REASSOCREQ:
- _mgt_dispatcher(padapter, ptable, precv_frame);
- break;
case WIFI_PROBEREQ:
- if (check_fwstate(pmlmepriv, WIFI_AP_STATE))
- _mgt_dispatcher(padapter, ptable, precv_frame);
- else
- _mgt_dispatcher(padapter, ptable, precv_frame);
- break;
case WIFI_BEACON:
- _mgt_dispatcher(padapter, ptable, precv_frame);
- break;
case WIFI_ACTION:
_mgt_dispatcher(padapter, ptable, precv_frame);
break;
--
1.7.10.4
On Wed, Feb 04, 2015 at 06:04:38AM -0500, Nicholas Mc Guire wrote:
> A few redundant switch cases as well as a redundant if/else
> within one of the cases was consolidated to a single call.
> The cases are intentionally retained for documentation purposes.
This statement is not clear. It obviously causes a bug if you just
start deleting case statements.
>
> Signed-off-by: Nicholas Mc Guire <[email protected]>
> ---
> case WIFI_REASSOCREQ,WIFI_PROBEREQ,WIFI_BEACON,WIFI_ACTION all
> have the same effect - notably the also for WIFI_PROBEREQ where
> the if/else is executing the same function.
>
> These redundant cases could all be dropped and consolidated into
> the default but probably it is better for documentation/readability
> to leave them in the switch/case explicitly.
Oh. This explains what you meant. Stop putting this information below
the cut off, it's annoying.
regards,
dan carpenter
Btw, what tool are you using to find these?
regards,
dan carpenter
On Wed, Feb 04 2015, Nicholas Mc Guire <[email protected]> wrote:
> A few redundant switch cases as well as a redundant if/else
> within one of the cases was consolidated to a single call.
> The cases are intentionally retained for documentation purposes.
>
[...]
> diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> index 28918201..cd12dd7 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> @@ -484,17 +484,8 @@ void mgt_dispatcher(struct adapter *padapter, struct recv_frame *precv_frame)
> /* fall through */
> case WIFI_ASSOCREQ:
> case WIFI_REASSOCREQ:
> - _mgt_dispatcher(padapter, ptable, precv_frame);
> - break;
> case WIFI_PROBEREQ:
> - if (check_fwstate(pmlmepriv, WIFI_AP_STATE))
> - _mgt_dispatcher(padapter, ptable, precv_frame);
> - else
> - _mgt_dispatcher(padapter, ptable, precv_frame);
It is highly unlikely that a function called check_fwstate has side
effects, but it might be nice checking that and making a note in the
commit log.
Rasmus
On Wed, 04 Feb 2015, Dan Carpenter wrote:
> Btw, what tool are you using to find these?
>
working on a set of coccinell scripts - they are not yet
really clean - but this one is simply:
virtual context
virtual patch
virtual org
virtual report
@assign@
position p;
statement S1;
@@
<+...
* if@p (...) S1 else S1
...+>
@script:python@
p << assign.p;
@@
print "%s:%s WARNING: condition with no effect" % (p[0].file,p[0].line)
I guess this is not wildly impressive - but it seems to be effective
in finding a lot of broken code. The rate of false postivs has been
supprisingly low (very few case of intentional if==else like in
./fs/kernfs/file.c:661 - which is nicely documented)
thx!
hofrat