Fix int overflow when using fillr in negative y-coordinates
- Also actually check the depth arg against the radius limit
- Fixes #973
If checking the depth size against max allowed radius should be done for fillr then it should also be done for fill, otherwise, the checkmaxradius in fillr should be removed, and the old default behaviour of "infinite depth" be re-added if no depth parameter is given
I don't understand how this fixes a negative y-coord issue. It seems like you only changed the value used if depth isn't passed, but I can't connect that to fixing y-coord issues if you passed e.g. 1 instead.
The depth is subtracted from the height of the player in the fillXZ method in editsession https://github.com/EngineHub/WorldEdit/blob/master/worldedit-core/src/main/java/com/sk89q/worldedit/EditSession.java#L1007. Using Integer.MAX_VALUE causes an overflow with negative values, so changing the default depth fixes it. It makes sense to also ensure that the depth does not exceed the max radius set, as it is effectively a radius in itself
Sounds like something that should be fixed in the method itself, because it's API -- people can still call it with MAX_VALUE and get bad behavior. Or pass MAX_VALUE as their depth in the command. This isn't a true fix if the method itself isn't protected against the overflow.
Separate to that (which would just be a bound to Integer.MIN_VALUE I suppose), should the depth be able to be larger than the max radius configured?
There are also other places overflows can occur, e.g. https://github.com/EngineHub/WorldEdit/blob/master/worldedit-core/src/main/java/com/sk89q/worldedit/EditSession.java#L1682