Re: Rethinking 64bit sizes and PHP-NG

From: 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

« previous php.internals (#74337) next »