Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65753
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5116D57F.6030802@ellisons.org.uk>
References: <511666DE.8080809@fedoraproject.org>
	<CAEZPtU7wNj3GDD6GbLkZ-6KRAV_62Hj5QYzGiD7kLObtEbfEmg@mail.gmail.com>
	<5116D57F.6030802@ellisons.org.uk>
Date: Sun, 10 Feb 2013 09:52:11 +0100
Message-ID: <CAEZPtU4-pB2wyTi0g38-jZh=JrSmif6ZD=C-WFHBPDPex-TPcg@mail.gmail.com>
To: Terry Ellison <Terry@ellisons.org.uk>
Cc: Remi Collet <remi@fedoraproject.org>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] double val to long val conversion issue
From: pierre.php@gmail.com (Pierre Joye)

hi Terry.

On Sun, Feb 10, 2013 at 12:02 AM, Terry Ellison <Terry@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 <remi@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