Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74337
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 74.125.83.48 cause and error)
Message-ID: <53789AD9.40109@lerdorf.com>
Date: Sun, 18 May 2014 13:34:49 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>
CC: Nikita Popov <nikita.ppv@gmail.com>, 
 PHP internals <internals@lists.php.net>
References: <CAF+90c8m8kMNjHOOKWs3iTxnLSVv41pk0mGjgzvvp2+Lieh+ig@mail.gmail.com>	<53788337.9090006@lerdorf.com> <CAEZPtU7XM3Sihz0KyEpfPpYMeLZXvrz-H8SmD4LnP9gDRjNXiA@mail.gmail.com>
In-Reply-To: <CAEZPtU7XM3Sihz0KyEpfPpYMeLZXvrz-H8SmD4LnP9gDRjNXiA@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/18/2014 12:13 PM, Pierre Joye wrote:
> 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.

You keep talking about side effects of the patch. It is these side
effects that we have a problem with. We need a version of the patch that
doesn't have all these undesired side effects.

You put the patch as it stands up for a vote and it is this patch we
have to vote on which is why I am voting no on it. It isn't some future
version with some unknown number of side effects removed.

-Rasmus