Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72134
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain oracle.com designates 141.146.126.69 as permitted sender)
Message-ID: <52F00F93.2020505@oracle.com>
Date: Mon, 03 Feb 2014 13:52:19 -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 <anatol.php@belski.net>, Anatol Belski <ab@php.net>
CC: PHP Developers Mailing List <internals@lists.php.net>,
        Matt Ficken <mattficken@php.net>,
        "Stephen A. Zarkos" <szarkos@php.net>
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com> <c3fa4f7710f1c4594386859cd15907dd.squirrel@webmail.klapt.com>
In-Reply-To: <c3fa4f7710f1c4594386859cd15907dd.squirrel@webmail.klapt.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: christopher.jones@oracle.com (Christopher Jones)



On 02/03/2014 01:10 PM, Anatol Belski wrote:
> On Mon, January 27, 2014 21:15, Anatol Belski wrote:
>> https://wiki.php.net/rfc/size_t_and_int64
>>
>>
>> There was two big questions regarding the compatibility. Those open
>> questions appeared in the discussions are reflected in the reworked RFC.
>>
>> First question, the possibility to keep the old zend_parse_parameters()
>> specs 'l', 'L', 's', 'p' along with new 'i', 'I', 'S', 'P'. Keeping the old
>> zpp specs will for sure minimize the porting effort for the PECL
>> extensions, but might lead to confusion (like people might think ‘l’
>> still expects ‘long’ and not ‘php_int_t’). Please use the yes/no Vote 3 to
>>   decide whether the ‘l’, ‘L’, ‘s’, ‘p’ have to stay supported.
>>
>> Second question, the macro renames for LONG<>INT, STRLEN<>STRSIZE, etc.
>> The reason for such renamings was to ensure source level incompatibility
>> on compile time. However this might have a negative effect on the porting
>> effort (despite the porting tools). Please use the yes/no Vote 2 to
>> decide whether the old macro names have to be kept.
>>
>> The Vote 1 is the main vote for this patch. The both Votes 2 and 3 are
>> merely to decide about the semantical replacements choosen for the patch.
>> Should the Votes 2 and 3 result in reverting of that semantical changes,
>> the essential patch part about the 64 bit support will not be hurt.
>> Reverting to old macro names or zpp specs is only the naming issue.
>>
>>
>> Removal of the dead SAPIs is isolated in a separate RFC and can be
>> considered to another time.
>>
>
> The RFC was rejected.
>
> Thanks for votes and constructive discussion. Based on the feedback in
> this thread, this RFC will be resurrected anytime soon.
>
> Best regards
>
> Anatol
>
>

Hi Anatol,

Thanks for all your work.

I look forward to a quick vote on whether to include it in PHP 5.7 or
PHP 6.0.  However, it would be useful to first know the schedule of
those releases, and the branching strategy.  It would be good to get
your patch into a branch that everyone is working on ASAP.

If your patch is approved for PHP 6.0 then I'm sure that you will be a
driving force in making sure PHP 6.0 stays on track. In fact, I can
foresee you becoming one of the PHP 6 RMs.

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