On 09/02/13 15:47, Pierre Joye wrote:
hi Remi
On Sat, Feb 9, 2013 at 4:10 PM, Remi Collet <r...@fedoraproject.org> wrote:
About
http://git.php.net/?p=php-src.git;a=commitdiff;h=79956330fe17cfd5f60de456497541b21a89bddf
(For now, I have reverted this fix)
Here some explanations.
LONG_MAX is 9223372036854775807 (0x7fffffffffffffff)
double representation of LONG_MAX is 9223372036854775808
(d > LONG_MAX) is evaluated in double space.
So is false for double which have the same value than (double)LONG_MAX.
So, for (double)LONG_MAX the cast used is
(long)d
9223372036854775807 on ppc64
9223372036854775808 on x86_64 (gcc without optimization)
9223372036854775807 on x86_64 (gcc -O2)
PHP expected value is 9223372036854775808
(Btw, I don't understand why PHP, build on x86_64, with -O2, gives the
good result, some environment mystery)
Obviously, we could have different result on different platform,
compiler, architecture.
I will be very interested by result on other platform (mac, windows),
compiler (Visual C), architecture.
If we switch to the unsigned cast:
(long)(unsigned long)d;
Any comments ?
IIRC, on windows/visualC, no matter if it is x86 or x64, long is
always 32bits, so it won't change the size of long.
See http://en.wikipedia.org/wiki/LLP64#64-bit_data_models for a good
description of this mess. AFAIK many packages that target both 32 and
64 bit environments MS and *nix, define explicitly adopt XXX_int32,
XXX_uint32, XXX_int64, XXX_uint64, ... datatypes and use wrappers to map
these onto the appropriate visualC / gcc types. As far as I can see,
PHP doesn't and seems to use long and int almost interchangeably which
causes problems as LP64/I32LP64 and LLP64/IL32P64 are very different.
This is one reason for 64-bit support on Windows being problematic.
It would be good for PHP to have a road map to removed data
model-specific potholes, say by 5.6 or 5.7.
//Terry
