Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65754
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.21 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Remi Collet" <remi@fedoraproject.org>, "Stas Malyshev"
 <smalyshev@sugarcrm.com>
Cc: "PHP Internals" <internals@lists.php.net>
References: <511666DE.8080809@fedoraproject.org>
 <51172819.4000806@sugarcrm.com> <51174790.8040805@fedoraproject.org>
 <511751C5.1020906@fedoraproject.org> <51175BDD.9040705@sugarcrm.com>
Date: Sun, 10 Feb 2013 12:00:01 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_I=2ES=2ET=2E?=
Message-ID: <op.wsad6bs3idpuyk@damnation.nl.lo.geleia.net>
In-Reply-To: <51175BDD.9040705@sugarcrm.com>
User-Agent: Opera Mail/12.12 (Linux)
Subject: Re: [PHP-DEV] double val to long val conversion issue
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

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