Welcome to the Builder Academy

# Question Might be a bug...

03 Aug 2022 16:02 #10115 by Errigour
Might be a bug... was created by Errigour
In cedit, Crashsave/Rent options if you change the crash file timeout and rent file timeout to 36500 it accepts the number but when the mud boots it deletes obj files for the players. Idk if its a bug but I thought I would post it. Also what is maximum those numbers can be?

Please Log in or Create an account to join the conversation.

03 Aug 2022 21:56 #10116 by thomas
Replied by thomas on topic Might be a bug...
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.
The following user(s) said Thank You: Errigour

Please Log in or Create an account to join the conversation.

Time to create page: 0.197 seconds