On Wed, Aug 22, 2018 at 8:48 PM, Nikolay Sivov nsivov@codeweavers.com wrote:
On 08/22/2018 06:49 PM, Ken Thomases wrote:
To be honest, I don't clearly remember why I put the float cast in there. I think perhaps to avoid potential (if unlikely) integer overflow. We want something like MulDiv() but always rounding toward zero. Perhaps just casting to INT64 would be better.
I like MulDiv better. Gabriel, do you think it's possible to get rid of some casts by changing variable types?
I don't think integer overflow is an issue. WHEEL_DELTA is defined as 120, which is not that big. That means the result would have to be larger than 2^31/120 (in magnitude), i.e. 17895697 (this is the result *after* the division). That's a pretty large number for the amount of lines to scroll. I don't think it's ever possible in practice :)
So honestly casting to INT64 sounds overkill to me.
As for reducing the amount of casts: I initially thought that pulScrollLines can't be signed because the function SystemParametersInfoW needs it unsigned (output parameter), however it seems it takes a PVOID. So I can just set pulScrollLines itself to INT and get rid of the casts. I'll prepare a v2 patch, also for the other float casting patch series.