Hey all,
I've found what I would call a bug (I submitted it as a feature
request, since that's probably more appropriate) with pow(). If any
one of the arguments is a float, it will cause the result to be a
float. On 32 bit systems this is fine, since all integers can be
exactly specified by the double precision float. But on 64 bit
systems, this can cause a loss of precision since only numbers up to
2^54-1 can be exactly represented. This actually caused me to have to
cast certain calls to ints to get them to behave correctly (as in this
line: https://github.com/ircmaxell/PHP-CryptLib/blob/master/lib/CryptLib/Random/Generator.php#L111
).
I've attached a patch which checks to see if both arguments can be
exactly represented by a long integer, and if so converts both to a
long, allowing a long to be returned. If either one of the arguments
is unrepresentable as a long (ex: 1.5), it will fallback on doing the
operation as a double (as it would now).
Additionally, while testing the patch, I found a tested-for-bug in the
64 bit test cases:
pow(-9.2233720368548E+18, 9223372036854775807) == INF
Clearly, that should be -INF due to the negative base and odd
exponent. But with the current code the odd portion of the exponent
is lost in the conversion to double (since it can't be representable),
and the exponent becomes even.
This patch changes that, since the base is exactly representable as a
long int, the power is done via the alternative algorithm.
https://bugs.php.net/bug.php?id=60789
What are your thoughts?
Thanks,
Anthony