Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74335
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 74.125.83.50 cause and error)
Message-ID: <53788337.9090006@lerdorf.com>
Date: Sun, 18 May 2014 11:53:59 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Nikita Popov <nikita.ppv@gmail.com>, 
 PHP internals <internals@lists.php.net>
References: <CAF+90c8m8kMNjHOOKWs3iTxnLSVv41pk0mGjgzvvp2+Lieh+ig@mail.gmail.com>
In-Reply-To: <CAF+90c8m8kMNjHOOKWs3iTxnLSVv41pk0mGjgzvvp2+Lieh+ig@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Rethinking 64bit sizes and PHP-NG
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 05/17/2014 08:27 PM, Nikita Popov wrote:
> So, that's my opinion on how we should proceed with the 64bit patch. I very
> much hope that we can reach some consensus about this.

Thanks for pulling this together Nikita. People have been asking me
about this issue and this was exactly what I told them we would likely
end up with as it is a sane and reasonable implementation of the two
efforts. I would guess an rfc vote between the alternatives, as I see
them, would favour this one by a wide margin.

As for >4G strings, it does seem unlikely, on current hardware, that you
would stick that much data in a variable. You might be able to get one
in there, but if you then do anything with it, the tmp copy is going to
make things fall over pretty quickly. But who knows in 4-5 years maybe
having a TB of ram in servers will be the norm, IO channels have become
much wider and we are manipulating 4K video files directly in PHP so
perhaps you can make a future-proofing argument there.

-Rasmus