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