On Sun, 10 Feb 2013 09:35:41 +0100, Stas Malyshev <smalys...@sugarcrm.com>
wrote:
So, looks like on ppc64 double->long conversion works differently than
on x86_64. Maybe best solution would be to make the patch with ifdef for
ppc64 so that it would do the same as Intel... Though I'm not sure if
somebody on this platform would expect PHP behave as C does, or as Intel
counterpart does. I'd say I personally probably would prefer
Intel-compatible behavior since most software would be expected to be
tested on Intel. But formally I'm not sure it's even wrong behavior...
I don't think the ifdef is needed at all. Like I said in the bug report,
I'm pretty sure that the patch is correct.
The idea of casting first to unsigned long when d > (double)LONG_MAX is to
use the extra range of unsigned long; if the double is within unsigned
long, the result is well-defined. But that test has a hidden assumption:
if d == (double)LONG_MAX, then we can cast to (long) because d is within
the long range. This assumption is wrong because (double)LONG_MAX is
larger than LONG_MAX -- the value 9223372036854775808.0 is the closest
double to 9223372036854775807. Therefore, changing the test to >= seems to
be the correct course of action.
My concern is that we may also have different behavior when we go outside
the unsigned long range.
As to whether ppc64 or x86_64 is correct when casting (double)LONG_MAX to
a signed long, the answer is this that since the double is outside long
range, the behavior is undefined. If we want more predictability, we have
to do the conversion ourselves and probably take a small performance hit.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
