Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65756
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.22 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>, "Gustavo Lopes" <glopes@nebm.ist.utl.pt>
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>
 <op.wsad6bs3idpuyk@damnation.nl.lo.geleia.net>
Date: Sun, 10 Feb 2013 15:58:28 +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.wsao7qs7idpuyk@damnation.nl.lo.geleia.net>
In-Reply-To: <op.wsad6bs3idpuyk@damnation.nl.lo.geleia.net>
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 12:00:01 +0100, Gustavo Lopes <glopes@nebm.ist.utl.pt>  
wrote:

> 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.

If we want to eliminate the undefined behavior, we should do (on archs  
with 64-bit longs):

(long)(unsigned long)(fmod(d, pow(2., 64.)))

Can you test this program on ppc64:

#include <stdio.h>
#include <math.h>

long convert(double d)
{
     return (long)(unsigned long)(fmod(d, pow(2., 64.)));
}

int main(int argc, char *argv[])
{
     double d;

     if (argc > 1 && sscanf(argv[1], "%lg", &d)) {
         printf("%ld %ld\n", convert(d), (long)(unsigned long)d);
     }
     return 0;
}

I get this:
$ gcc -O3 -lm conv.c && ./a.out 9223372036854775808
-9223372036854775808 -9223372036854775808
$ gcc -O3 -lm conv.c && ./a.out 4e21
-2943463994972700672 0
$ gcc -O3 -lm conv.c && ./a.out 4e19
3106511852580896768 0

Which seems correct when verified with mathematica:

In[9]:= c =
   Function[o,
    o // N // SetPrecision[#, \[Infinity]] & // Mod[#, 2^64] & //
     Piecewise[{{#, # < 2^63}}, -2^64 + #] &];

In[10]:= c /@ {2^63, 4*^21, 4*^19}

Out[10]= {-9223372036854775808, -2943463994972700672, \
3106511852580896768}

The cast to long from unsigned long is still implementation-defined  
behavior, but all twos complement archs should work like this (i.e. don't  
change the representation). In any case, it's not undefined behavior.

-- 
Gustavo Lopes