Hide Forgot
Description of problem: Prior to PHP 4.3.6 the mod argument to gmp_powm() could be a hexadecimal string, in the new version it must be passed to gmp_init() first. This breaks compatibility with older code. Version-Release number of selected component (if applicable): php-4.3.6 Actual Results: With PHP 4.3.6 % echo '<?php var_dump(gmp_powm("0x123", "0x123", "0x123")) ?>' | php -q bool(false) Expected Results: With PHP 4.3.4 % echo '<?php var_dump(gmp_powm("0x123", "0x123", "0x123")) ?>' | php -q resource(4) of type (GMP integer) This is apparently caused by a change in php 4.3.5 or 4.3.6, ext/gmp/gmp.c, line 833: convert_to_long_ex(mod_arg); Running convert_to_long_ex() on anything but normal 32 bit numbers will break things.
PHP 4.3.7 was just released, but unfortunately my patch for the problem didn't make it in the release. If you are planning on updating the Fedora packages to 4.3.7 please include my fix for this bug: http://bugs.php.net/bug.php?id=28525
Thanks for the report. Could you provide a (minimal) valid test case for this if, as Ilia states, it is not valid to pass hex strings? A patch along with such a test case may receive better reception upstream too :)
I added some more information about the case in my php.net bug report, and it has now been fixed in CVS.
OK, great, we'll include the fix in the 4.3.7 update.
4.3.8 updates including your patch are now available for testing from: http://people.redhat.com/jorton/FedoraC1-php/ Please post results of any testing.
The update rpms seem to fix the issue, but apparently also add a dependency from php to php-mbstring.
That's deliberate, up2date and yum will handle it correctly. This update has now been made live. Thanks for the report and for chasing this upstream. http://www.redhat.com/archives/fedora-announce-list/2004-July/msg00026.html