Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71404
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.181 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <d27df615bc27d701daceb5ee605f540f.squirrel@webmail.klapt.com>
References: <d27df615bc27d701daceb5ee605f540f.squirrel@webmail.klapt.com>
Date: Wed, 22 Jan 2014 11:56:12 +0100
Message-ID: <CAMUwpuSKDCS4g-Luy2QphBg0CFfGb=Dbpm0BuenRzYchAnrAWg@mail.gmail.com>
To: Anatol Belski <ab@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [RFC] 64 bit improvements, open questions
From: jpauli@php.net (Julien Pauli)

On Wed, Jan 22, 2014 at 9:20 AM, Anatol Belski <ab@php.net> wrote:
> Hi,
>
> as the discussion phase for this RFC nears to the finish and the patch
> itself is huge, I'd like to use the last chance to discuss the open
> questions and concerns. Here are once more the links to the RFC (with
> several updates) and the porting guide
>
> https://wiki.php.net/rfc/size_t_and_int64
> http://git.php.net/?p=php-src.git;a=blob;f=compat/PECL_PORTING;hb=refs/heads/str_size_and_int64
>
> The big open question from the previous discussion is how to handle
> changed ZPP formats. The way I've suggested in the porting doc is using
> ternary operator like (COMP ? "l" : "i"). Another way were to put the old
> ZPP formats "lLsp" back and make them redundant to the new ones "iISP".
> Both ways have their pro and contra, the second variant isn't done, but
> can be done quickly.

That's a good question.
Having to check for a macro and adapt parameters at every zpp() call
would be painful, however we already do such things in other scenarios
to take care of compatibility, so ...
I would however rename the macro to something more meaningfull, same
for PHP_NEED_COMPAT which should be named something like
PHP_NEED_STRSIZE_COMPAT

> Also one big question from the RFC which haven't been addressed is the
> handling of the stale SAPIs. While porting it turned out, that more than
> 50% of SAPIs reference no more actively supported web servers, some of
> them are even not available anymore, no packages in the current
> distributions seem to exist, no chance to check if they even complaint
> with PHP mainstream. The SAPIs ported so far - apache2handler, CGI, CLI,
> embed, FPM, phpdbg.

I would suggest getting rid of those old SAPIs nobody use anymore.
Late 90's SAPI that are not used/maintained anymore can die , IMO.


I also have a memory usage question.
Have we measured the impact of extending all 32 ints to 64 ? Memory
usage should be higher, but how many higher ?

Then is all that compatible with OPCache ?
I guess yes and see nothing which would be blocking, anyway better ask.


Anyway I'm all OK to merge this to 5.6 (should the RFC be accepted),
this is a great push in PHP crossplatform handling, thanks for the
huge work done so far !


Julien