Closed ottonemo closed 8 months ago
Hi, English is not my native language, I'm not sure I will be able to explain it clearly.
It is by design that there is this overflow.
You must remember that OsTime
will overflow regularly (every 19 hours).
and sometime b is greate than a in a-b, for exemple if we have a "due time" and "current time", sometime due time is less than current time. We can't compare directly OsTime.tick()
we need to compare the difference and cast it to int32
Some case:
due_time = 0xFFFFFFFE , current_time = 0x2 => due time passed, 4 tick late (-4)
The only problem is when difference is greater than 9h.
Using your method ((time_now.tick() - time_previous.tick()) >= (uint32_t) threshold)
will only work if time_now is always after time_previous.
Fair :) Thanks for explaining!
Hey,
thank you for the project, it is really useful!
While using the
OsTime
andOsDeltaTime
interface I stumbled upon a possible integer overflow that I wanted to discuss.Consider the following example:
Internally subtraction is defined as
Now the backing type of
OsDeltaTime
isint32
whileOsTime
usesuint32
. IfOsTime a
is >2**31
the above statement would result inOsDeltaTime((int32) 2**31+1 - 0)
which would clearly overflowint32
and be a negative delta time even though it would need to be positive.Currently I'm using raw tick values to work around this (
(time_now.tick() - time_previous.tick()) >= (uint32_t) threshold
) but it might lead to unexpected behavior down the line so I thought it is worthwhile reporting it.