Fix GH-16870: gmp_pow(64, 11) throws overflow exception

[cmb69]

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

php-src/ext/gmp/tests/gmp_pow_fpe.phpt

Lines 20 to 29 in ff3b4ec

	try {
	gmp_pow(gmp_add(gmp_mul(gmp_init(PHP_INT_MAX), gmp_init(PHP_INT_MAX)), 3), 256);
	} catch (\ValueError $e) {
	echo $e->getMessage() . PHP_EOL;
	}
	try {
	gmp_pow(gmp_init(PHP_INT_MAX), 256);
	} catch (\ValueError $e) {
	echo $e->getMessage();
	}

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.

[cmb69]

The threshold logic should be unified with #16880 and other places in gmp.c.

[Girgias]

Don't we just care if it can be "allocated reasonably" ?
Which is actually somewhat described in section 5.14 of the GMP manual (mpz_export)

Wonder if we shouldn't use a heuristic based on that?

[cmb69]

This is basically what is already happening in this patch. The difference is that I'm counting bytes, not bits. The logic is to estimate the number of bytes the result would have, and if this is greater than some threshold (powmax is badly named; should be rather max_size_in_bytes or so), trigger a value error.

mpz_sizeinbase() is only used in the else branch, because if the input is a zend_long, that wouldn't work. So I'm calculating log256(base_arg) * exp instead.

I'll update to counting bytes.

[cmb69]

Oh, I had only checked with 64bit builds, but now noticed that two test cases are failing on 32bit. I could further reduce max_bits, but I think gmp_pow(20,10) should actually succeed (result is a number with only 14 decimal digits; even 20**10 works); same for the others that are now failing. Maybe we can agree on a threshold (max_bits) first; I will then adapt test cases as needed (and also rebase, if we do not want to target any stable branches).