Int overflow, then the result can be negative, so function breaked

[nguyenbantran]

Dear @ifesdjeen, In this line, int firstFireOffset = (int) (firstDelay / resolution), firstFireOffset maybe is negative if firstDelay is so large.

I think all variable around should be long, and we just need cast to int when access wheel[index]. Please review this problem.

https://github.com/ifesdjeen/hashed-wheel-timer/blob/6dfa8a8c99b0df16e21c9410f31bd186cfb6b0c0/core/src/com/ifesdjeen/timer/HashedWheelTimer.java#L396

Thanks and best regards,

[mz0113]

Dear @ifesdjeen, In this line, int firstFireOffset = (int) (firstDelay / resolution), firstFireOffset maybe is negative if firstDelay is so large.

I think all variable around should be long, and we just need cast to int when access wheel[index]. Please review this problem.

https://github.com/ifesdjeen/hashed-wheel-timer/blob/6dfa8a8c99b0df16e21c9410f31bd186cfb6b0c0/core/src/com/ifesdjeen/timer/HashedWheelTimer.java#L396

Thanks and best regards,

int firstFireOffset = (int) (firstDelay / resolution); if firstFireOffset overlimit , firstDelay must be so large ,for example : firstDelay = 10ms * MAX_INTEGER , actually , i think it can be regard as never happen , we write code for using instead of extreme correctness

[nguyenbantran]

Dear @ifesdjeen, In this line, int firstFireOffset = (int) (firstDelay / resolution), firstFireOffset maybe is negative if firstDelay is so large. I think all variable around should be long, and we just need cast to int when access wheel[index]. Please review this problem. https://github.com/ifesdjeen/hashed-wheel-timer/blob/6dfa8a8c99b0df16e21c9410f31bd186cfb6b0c0/core/src/com/ifesdjeen/timer/HashedWheelTimer.java#L396 Thanks and best regards,

int firstFireOffset = (int) (firstDelay / resolution); if firstFireOffset overlimit , firstDelay must be so large ,for example : firstDelay = 10ms * MAX_INTEGER , actually , i think it can be regard as never happen , we write code for using instead of extreme correctness.

Normally, this can not happen, but if in some cases when you receive the time to do scheduling from user input, you can get a very long time. (An example use-case: you will start an event at Start_Time, then stop it at Stop_Time, and Stop_Time normally just is guaranteed greater than Start_Time and maybe the current time).

You can have two options:

• Don't schedule when the Stop_Time is so long in the future.
• Don't care about Stop_Time, and update the library to schedule it even it's so long in the future.

Because the fix is not hard, so I fixed the library (in my internal product), but the source code is hard to build so I can not build the library successfully without modify other configuration, I fear it will break the release process, so I didn't make a PR.