hi Terry. On Sun, Feb 10, 2013 at 12:02 AM, Terry Ellison <te...@ellisons.org.uk> wrote: > 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. Yes, that's the case, see my other reply in this thread. > It would be good for PHP to have a road map to removed data model-specific > potholes, say by 5.6 or 5.7. I do not think this change is small enough to be done in 5.x but definitively in the next major. We have to keep in mind the impacts of such a change on the code base and all external projects, be extensions or libraries used by PHP. In addition, buffers size should use (u)size_t and not int32/64. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
