Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74038
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
Message-ID: <9ffd750d6162d87f48286491f06d93cd.squirrel@webmail.klapt.com>
In-Reply-To: <5368E018.2040609@lsces.co.uk>
References: <a1b3a511b2e0163fd87a6ab639c52817.squirrel@webmail.klapt.com>
    <alpine.DEB.2.10.1405060956350.4404@whisky.home.derickrethans.nl>
    <8b32b5b5b6d14c0c7aff1cb52087820f.squirrel@webmail.klapt.com>
    <5368E018.2040609@lsces.co.uk>
Date: Thu, 8 May 2014 00:06:57 +0200
To: "Lester Caine" <lester@lsces.co.uk>
Cc: internals@lists.php.net
User-Agent: SquirrelMail/1.5.2 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] 64 bit platform improvements for string length
 and integer
From: anatol.php@belski.net ("Anatol Belski")

Hi Lester,

On Tue, May 6, 2014 15:14, Lester Caine wrote:
> On 06/05/14 11:58, Anatol Belski wrote:
>
>>> I'm afraid with all those concerns, I will have to vote "no".
>>>
>>>>
>> Of course that would make me sad. Not only for the work done on that,
>> but also for the future perspectives and for the quantity of the users
>> who wish such thing.
>
> Having just been going through an exercise to convert Windows XP sites
> to something M$ will allow to run without warning messages, the switch to a
> more modern windows would seem sensible. Except we have been restricted to
> using 32bit builds of windows for compatibility with the hardware. While
> parts of PHP already require 64 bit integers which are handled in an even
> less efficient way, switching to a clean 64 bit integer across all
> platforms really is essential. Having to manage the difference in the user
> code base is simply not an option :(
>
> The switch to a cleaner implementation base should allow proper planning
> for that requirement?
>
absolutely, furthermore - Windows Server 2012 (and probably any upcoming)
is not merchandased with 32-bit edition anymore. For 32 bit PHP there it
means possible performance penalty. So usage of the true 64 bit PHP fully
makes sense there.

Regards

Anatol