[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <60b97eea-c8ac-9f9b-6c7b-903124e9ae51@lwfinger.net>
Date: Thu, 31 Aug 2023 12:59:00 -0500
From: Larry Finger <Larry.Finger@...inger.net>
To: Michael Büsch <m@...s.ch>,
Ранд Дееб <deeb.rand@...fident.ru>
Cc: linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
lvc-project@...uxtesting.org,
Воскресенский Станислав Игоревич
<voskresenski.stanislav@...fident.ru>
Subject: Re: [PATCH] ssb-main: Fix division by zero in ssb_calc_clock_rate()
On 8/31/23 11:05, Michael Büsch wrote:
> On Thu, 31 Aug 2023 10:07:33 +0300 (MSK)
> Ранд Дееб <deeb.rand@...fident.ru> wrote:
>
>> 1- Yes, I agree that your solution is simpler, and I thought about
>> it, but I thought that the one who set the value zero put it for some
>> reason, so I did not want to change it.
>
>
> Yes, I understand your reasoning and I had the same thought initially.
> But I looked into the code and I am pretty sure that there is no reason
> for the default case returning 0.
> In fact, I think returning a 1 as default makes much more sense as the
> default value for a factor.
>
> Changing this from 0 to 1 will get my ack.
As far as I can tell, that return 0 is there only to silence the compiler as the
switch statement has no default. As I said earlier, there have been no reports
of divide by zero entries in this ancient driver, thus the value returned is not
relevant. As a static tool sees the possibility of a returned zero leading to a
potential divide by zero, making it a one it the only thing that makes sense.
I have no idea why this part of the patch has led to so much discussion!
Larry
Powered by blists - more mailing lists