What happens with integer overflow?

[FuryoftheStars]

I'm curious how this game/lua handles integer overflows. Specifically uint (but if it's different depending on the number type in question, knowing all could be good). Does it just roll over to the other end? Does it generate an error or undefined value?

[DaveMcW]

All Lua 5.2 numbers are double precision floats. So it almost impossible to make them overflow.

[FuryoftheStars]

Ok, then maybe it's the C++ side I'm interested in? Basically, I want to know what happens to a number like game.tick (which the docs show as a uint) when it overflows. Does it restart at 0, or does it generate some kind of undefined value and/or error out?

[DaveMcW]

C++ integers wrap around to the minimum value. This does not affect the number itself, but any logic expecting the number to be large could fail/crash.

game.tick overflow is a popular source of bugs, some of which have been fixed. I'm not sure they are all fixed though.

[FuryoftheStars]

Ok, thanks! In my case, with the mod I'm modifying, I'm taking game.tick and adding an additional number to it before storing it away. While this obviously shouldn't be an issue for a long time, I just wanted to make sure it wouldn't start causing crashing or anything when someone starts nearing the end of the map's game.tick. The fact that it wraps around is actually good and... I think... I shouldn't have to do anything special to catch.

[Xorimuth]

Ok, thanks! In my case, with the mod I'm modifying, I'm taking game.tick and adding an additional number to it before storing it away. While this obviously shouldn't be an issue for a long time, I just wanted to make sure it wouldn't start causing crashing or anything when someone starts nearing the end of the map's game.tick. The fact that it wraps around is actually good and... I think... I shouldn't have to do anything special to catch.

If the player is approaching the max value of game.tick then that's very much the player's problem (or wube's), not yours as a modder. See 101341 and viewtopic.php?f=18&t=101621 for more info.

[FuryoftheStars]

Ok, thanks! In my case, with the mod I'm modifying, I'm taking game.tick and adding an additional number to it before storing it away. While this obviously shouldn't be an issue for a long time, I just wanted to make sure it wouldn't start causing crashing or anything when someone starts nearing the end of the map's game.tick. The fact that it wraps around is actually good and... I think... I shouldn't have to do anything special to catch.

If the player is approaching the max value of game.tick then that's very much the player's problem (or wube's), not yours as a modder. See 101341 and viewtopic.php?f=18&t=101621 for more info.

Yes, I'm fully aware. However, I don't want to contribute to the problem, plus, right in one of the threads you linked, the devs gave a "fix" to reset the counter so the map can continue being used: viewtopic.php?p=560436#p560436

I want to be forward thinking here and not have this mod be a reason why they cannot, or force them into uninstalling/reinstalling the mod.

[robot256]

If you are doing math with game.tick and equality comparisons, you can account for the rollover. For example, "tick_to_wait_for = math.mod(game.tick+1000, 2^32)". If you are doing less than/greater than comparisons, then some extra logic will be required to handle the rollover, and possibly a memory of the "last tick" to trigger it.

[FuryoftheStars]

Nah, I'm just doing a game.tick + factor, then using the result as the index in a table. Later, I recall data out of the table with the current game.tick (and once done processing what was stored there, I nil it). So if it rolls over to 0, that should be no issue in my use case.

[robot256]

At tick 2^32-1, you calculate future_index=2^32-1+factor, which is a large positive number. It will never test equal to any subsequent game.tick values, because they roll over from 2^32-1 to 0, 1, 2 etc. So to make your code rollover proof you have to detect when future_index exceeds 2^32-1 and store the rolled-over value too. Otherwise you could have some stale entries for 2^32+N that never get deleted or acted on.

[FuryoftheStars]

Wait... so can my math exceed 2^32? Shoot... I've been assuming that when I do math operations, it's still treating it as a 32-bit number. Now that I think about it, I guess I should've known better.

[robot256]

Once it's in Lua, it stays as a double (52-bit integer capable) until you pass it back to another API function.

[FuryoftheStars]

Ok, so a test of “is result >= 2^32, and if so, subtract 2^32 from it” should work.

Thanks!