Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71702
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: <52E81C47.7040705@oracle.com>
Date: Tue, 28 Jan 2014 13:08:23 -0800
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com>	<CAF+90c-W+un8BsBD3OAeVL05s3iM5RxGnOD2Xa7nBPC+TuPijg@mail.gmail.com>	<CAEZPtU6rvmrfrX73jRim1pz-76t8ThdAkOoP-0ygc3KG9GaxUw@mail.gmail.com> <CAF+90c8-ELB=jw3V5HiJLMSU4tTUypjP-EgMpnYzDXuHLFsNxg@mail.gmail.com>
In-Reply-To: <CAF+90c8-ELB=jw3V5HiJLMSU4tTUypjP-EgMpnYzDXuHLFsNxg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: christopher.jones@oracle.com (Christopher Jones)



On 01/28/2014 12:51 PM, Nikita Popov wrote:
> On Tue, Jan 28, 2014 at 9:33 PM, Pierre Joye <pierre.php@gmail.com> wrote:
>
>>> Just to clarify my vote: I voted "No" on the RFC, but only because I
>> think
>>> the major extension source API break is better suited to PHP 6 than PHP
>>> 5.6. I fully support merging this into master, as the first change for
>> PHP
>>> 6.
>>
>> Sad. As the work for pecl extensions is really not as large as you
>> think, fairly straight forward. The vote for php6 is not running now.
>> There is no option for PHP 6 as what can be done in php 6 internally
>> is much larger and would allow more breakage. On the other side, we
>> provide options to minimize the work for the extensions developers in
>> order of magnitude smaller than the changes we introduced in the past
>> for the OO APIs for example.  Anyway, sad that you voted no for
>> something as important than true 64bit support.
>>
>
> Maybe I'm indeed overestimating the impact. Could you please link to the
> source-code for a PECL (or other third-party) extension that was ported to
> be compatible with the new API, so people can see the actual impact this
> makes? (Hopefully some ext that requires compat across multiple versions
> like 5.3+ and has non-trivial amount of code and functions, like a few
> dozen.) I couldn't find an example in RFC, but maybe I just missed it. Only
> saw small snippets in there.
>
> Nikita
>

You could do a diff with OCI8 on str_size_and_int64 vs. master to see
one example.

I also have some additional unmerged patches related to a comment you
may see "/* XXX we assume that zend-zval len has 4 bytes */" since the
zval len is now a size_t and no longer 32 bits. I have more investigation
to do.

If the ZPP specs are not portable (vote #3), an additional 53 calls to
it will need #ifdef'ing so the code base is portable to older PHP
releases (because OCI8 is also released on PECL).

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