Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74336
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <53788337.9090006@lerdorf.com>
References: <CAF+90c8m8kMNjHOOKWs3iTxnLSVv41pk0mGjgzvvp2+Lieh+ig@mail.gmail.com>
	<53788337.9090006@lerdorf.com>
Date: Sun, 18 May 2014 12:13:08 +0200
Message-ID: <CAEZPtU7XM3Sihz0KyEpfPpYMeLZXvrz-H8SmD4LnP9gDRjNXiA@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Rethinking 64bit sizes and PHP-NG
From: pierre.php@gmail.com (Pierre Joye)

On Sun, May 18, 2014 at 11:53 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> 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.

It is exactly what we have been advocating during the whole process.
More about that in a mail I'm writing.


> 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.



The string length is a side effect, not a goal per se, never was. But
variables, buffers dealing with external libraries or functions are
sensible areas. A safe implementation will prevent many issues we
already had, many times. Also correct typing and less (if not none)
magic casting guessed by the compiler will also drastically increase
PHP code quality and safety. These two points, and 64bit integer in a
portable manner, are the top goals of this RFC.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org