Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71698
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c-W+un8BsBD3OAeVL05s3iM5RxGnOD2Xa7nBPC+TuPijg@mail.gmail.com>
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com>
	<CAF+90c-W+un8BsBD3OAeVL05s3iM5RxGnOD2Xa7nBPC+TuPijg@mail.gmail.com>
Date: Tue, 28 Jan 2014 21:33:13 +0100
Message-ID: <CAEZPtU6rvmrfrX73jRim1pz-76t8ThdAkOoP-0ygc3KG9GaxUw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Anatol Belski <ab@php.net>, PHP Developers Mailing List <internals@lists.php.net>, 
	Matt Ficken <mattficken@php.net>, "Stephen A. Zarkos" <szarkos@php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: pierre.php@gmail.com (Pierre Joye)

On Tue, Jan 28, 2014 at 9:23 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Mon, Jan 27, 2014 at 9:15 PM, Anatol Belski <ab@php.net> 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.
>>
>> Thanks for the constructive discussions on this RFC, support and testing.
>> The vote begins Monday, 27 January 2014, 21:30 CET and ends Monday, 03
>> February 2014, 21:30 CET.
>>
>
> 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.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org