On Thu, 31 Aug 2023 10:07:33 +0300 (MSK)
Ранд Дееб <[email protected]> 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.
--
Michael Büsch
https://bues.ch/
On 8/31/23 11:05, Michael Büsch wrote:
> On Thu, 31 Aug 2023 10:07:33 +0300 (MSK)
> Ранд Дееб <[email protected]> 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