[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210225105135.6a2e6953@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Thu, 25 Feb 2021 10:51:35 -0800
From: Jakub Kicinski <kubakici@...pl>
To: Colin King <colin.king@...onical.com>
Cc: Kalle Valo <kvalo@...eaurora.org>,
"David S . Miller" <davem@...emloft.net>,
Matthias Brugger <matthias.bgg@...il.com>,
linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org,
kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mt7601u: fix always true expression
On Thu, 25 Feb 2021 18:32:41 +0000 Colin King wrote:
> From: Colin Ian King <colin.king@...onical.com>
>
> Currently the expression ~nic_conf1 is always true because nic_conf1
> is a u16 and according to 6.5.3.3 of the C standard the ~ operator
> promotes the u16 to an integer before flipping all the bits. Thus
> the top 16 bits of the integer result are all set so the expression
> is always true. If the intention was to flip all the bits of nic_conf1
> then casting the integer result back to a u16 is a suitabel fix.
>
> Interestingly static analyzers seem to thing a bitwise ! should be
> used instead of ~ for this scenario
In what way? The condition is nic_conf1 != 0xffff AFAICT, how would we
do that with !?
> so I think the original intent
> of the expression may need some extra consideration.
>
> Addresses-Coverity: ("Logical vs. bitwise operator")
> Fixes: c869f77d6abb ("add mt7601u driver")
> Signed-off-by: Colin Ian King <colin.king@...onical.com>
Acked-by: Jakub Kicinski <kubakici@...pl>
Thanks for the fix!
Powered by blists - more mailing lists