Re: Rethinking 64bit sizes and PHP-NG
| From: | Rasmus Lerdorf | Date: | Sun, 18 May 2014 11:34:49 +0000 |
| Subject: | Re: Rethinking 64bit sizes and PHP-NG | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-74337@lists.php.net to get a copy of this message | ||
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