The current guard to prevent FPEs is way too restrictive; 64 ** 11 is a perfectly reasonable operation. Instead, we now estimate the number of bytes of the resulting GMP (assuming that numbers are stored base 256 encoded), and fail if that exceeds a given threshold. The chosen threshold is somewhat arbitrary.

We also ensure that we do not prematurely convert a given non int base to an int to avoid overflow which could circumvent our early check.

Note that the threshold of 2000 seems way too small. To avoid triggering overflow handling during allocations it should rather be close to SIZE_MAX (or whatever libgmp/mpir assume there), but even 10,000 would cause

to no longer throw, but instead yield reasonable results: numbers with a bit less than 10,000 and 5,000 digits, respectively. It's hard for me to tell whether these examples would actually cause libgmp's overflow check to trigger, since mpir doesn't even have these overflow checks.

In any way, it might not be the best idea to push the limits of our early overflow check just to avoid overflow checks to be triggered by libgmp, since we're likely hitting OOM, which causes abort.