Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71699
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.173 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:36:42 +0100
Message-ID: <CAEp07h-NZpJ9BpKPgeoCxGaY16NZ20+KNZRhm3ny0FMvkCMRXw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: "Stephen A. Zarkos" <szarkos@php.net>, Matt Ficken <mattficken@php.net>, 
	PHP Developers Mailing List <internals@lists.php.net>, Anatol Belski <ab@php.net>
Content-Type: multipart/alternative; boundary=f46d0444ea9938cb1704f10dc8ef
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: martin.keckeis1@gmail.com (Martin Keckeis)

--f46d0444ea9938cb1704f10dc8ef
Content-Type: text/plain; charset=UTF-8

Am 28.01.2014 21:24 schrieb "Nikita Popov" <nikita.ppv@gmail.com>:
>
> 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.
>
> Nikita

Sadly...
(From a long waiting Php user, who dont want to wait 2-3 years...)

--f46d0444ea9938cb1704f10dc8ef--