The codebase lacks consistent bounds checking, leading to overflows in g/h/f-values. While often caused by high action costs, for some heuristics like hadd or hff, this already occurs for moderate-sized STRIPS tasks (see issue240).

Current workarounds, like clamping in h^{add}, are undocumented.

We want a unified approach to handling these overflows. Key points from a discussion:

1. Reporting: Detect and report when bounds are exceeded.
2. Performance: Arbitrary-precision integers (e.g., GMP) are considered overkill and would impact performance too heavily in tight loops.
3. 64-bit Quantities: Moving to 64-bit signed integers for specific values would increase the limit 9,223,372,036,854,775,807 (significantly reducing limitations).
4. Templatization: Templatizing certain components (similar to variable domain sizes in the past) would allow us to balance expressiveness and speed by switching representations where needed.

f values can also exceed the bounds much more quickly when using Weighted A*.

State IDs and operator IDs can also overflow.

From the discussions in the community that I can remember, the state ID limit is the only one where I remember people mention that it was a real problem for them, and at least one research group modified Fast Downward to be able to have more states.

So when we get to work on overflow checking, we should also keep these in mind.