Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71413
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain oracle.com designates 156.151.31.81 as permitted sender)
Message-ID: <52E01DDA.4020404@oracle.com>
Date: Wed, 22 Jan 2014 11:36:58 -0800
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Anatol Belski <ab@php.net>
CC: PHP internals <internals@lists.php.net>
References: <d27df615bc27d701daceb5ee605f540f.squirrel@webmail.klapt.com> <2ecdbcfc1725e25ccad4705429dbfa2f.squirrel@webmail.klapt.com>
In-Reply-To: <2ecdbcfc1725e25ccad4705429dbfa2f.squirrel@webmail.klapt.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] 64 bit improvements, open questions
From: christopher.jones@oracle.com (Christopher Jones)



On 01/22/2014 01:09 AM, Anatol Belski wrote:
> On Wed, January 22, 2014 09:20, Anatol Belski 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/hea
>> ds/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.
>>
>> 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.
>>
>> Please respond also if you have any other concerns about this RFC.
>>
>>
>> The voting phase is likely to be started on Sunday, January 22.
>>
>
> Sunday, January 26 - that's correct :)
>
> Regards
>
> Anatol
>
>

Hi Anatol,

This is a huge patch - kudos.  However it will cause some short term
instability.  It's the kind of deep change that typically would be
merged at the beginning, not the end, of a release process.

The new code will require time to stabilize.  For example, there are
some new OCI8 diffs that will require debugging.  There is one OCI8
code block in PHP-5.6 that isn't in the str_size_and_int64 branch.
(I'll send details separately).  It's likely other extensions will be
similarly subtly impacted.

The open issues (e.g. SAPI support) need to be resolved before
starting the vote, so the RFC direction is obvious.  Also the RFC
needs to discuss proposed voting options, prior to starting the vote.
Since that only gives a couple of days for discussion, I think you
should delay the vote.

The porting doc compat/PECL_PORTING should be merged into the RFC (and
removed from the tree) to capture as much information in the one place
as possible.

Chris

-- 
christopher.jones@oracle.com  http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html