Re: double val to long val conversion issue

On Sun, 10 Feb 2013 09:35:41 +0100, Stas Malyshev <smalyshev@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