Yes, this sounds like a bug. The comparison here is done like this:
Code:
if (timed < time(0) - (CONFIG_RENT_TIMEOUT * SECS_PER_REAL_DAY)) {
Here, "timed" is the time of the saved file. This will typically be something like 1659561000 (seconds since the epoch). It is stored in an int.
Likewise, time(0) will return something of the same magnitude, 1659562099 (seconds
now). It returns a time_t type (which is a long int).
CONFIG_RENT_TIMEOUT is your configured timeout, 36500.
SEC_PER_REAL_DAY is 24*60*60 = 86400.
This translates to this calculation:
Code:
if (1659561000 < 1659562099 - ((int)36500 * (int)86400))
Or
Code:
if (1659561000 < 1659562099 - ((int)3153600000))
But int has a max value of 2147483647 and a min value of -2147483648.
If you pass this, you will "wrap around" and get a negative number:
Code:
if (1659561000 < 1659562099 - ((int)-1006116353))
And, since minus+minus is plus, you get:
Code:
if (1659561000 < 1659562099 + 1006116353)
And this is obviously true.
So, what can be done?
Well, as a workaround, keep your max rent days under MAX_INT/SECS_PER_REAL_DAY = 2147483647/(24*60*60) = 24855.
Apart from that, one could explicitly cast as long long ints in the actual calculation. This gives plenty of space, even if someone put in MAX_INT as a limit. I'll make a bug report on github about this.
