Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71918
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.180 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <9810c708a9fcc543a263365b5d7c2a63@mail.gmail.com>
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com>
	<1391171792.2941.130.camel@guybrush>
	<52EB9A16.5060605@phpdoc.de>
	<1391172906.2941.140.camel@guybrush>
	<9810c708a9fcc543a263365b5d7c2a63@mail.gmail.com>
Date: Sat, 1 Feb 2014 12:04:46 +0000
Message-ID: <CAEKnhAG+4F2xoGZBkN5fBCa4mDE+3c-CMOUA_LBmtXboLvmg6g@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2bd84c3680c04f15718b3
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: bukka@php.net (Jakub Zelenka)

--001a11c2bd84c3680c04f15718b3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 31, 2014 at 9:21 PM, Zeev Suraski <zeev@zend.com> wrote:

> > -----Original Message-----
> > From: Johannes Schl=FCter [mailto:johannes@schlueters.de]
> > Sent: Friday, January 31, 2014 2:55 PM
> > To: Ulf Wendel
> > Cc: internals@lists.php.net
> > Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string
> > length and integer
> >
> > On Fri, 2014-01-31 at 13:41 +0100, Ulf Wendel wrote:
> > > Am 31.01.2014 13:36, schrieb Johannes Schl=FCter:
> > > > I think adding this patch to 5.x therefore would be quite some
> > > > bending of that rule and that combined with the fact that it is lat=
e
> > > > makes me believe that proposing this for 5.6 is illegal.
> > >
> > > Are you saying the RFC is 'illegal' ? If the subject proposed is not
> > > allowed, it would make litte sense collecting votes.
> >
> > I think the RM has to reject this from 5.6 independently from the votin=
g
> > result as he is bound by the release process RFC.
>
>
> All,
>
> I have to add something here.
>
> Many of the people voting on that RFC have never ever contributed as much
> as
> a single line of code into the PHP source tree, and a couple have literal=
ly
> contributed low-single-digit patches.
> Incidentally, as far as I could tell, all of them[*] voted in favor of th=
e
> proposed changes (i.e. source compatibility breakage).
>
> Even though having non-code-contributors makes a lot of sense for decisio=
ns
> regarding the language's features and we built in support for it in the
> voting RFC, in my opinion, it makes no sense at all for people who have n=
o
> stake at the development of the language's source code to weigh in on how
> that code is written.  Personally I didn't expect we'd be voting on thing=
s
> like that (implementation style) back when I was involved in the voting
> RFC,
> but perhaps it's time to amend it a bit.
>
> If you fall in that category, please do the right thing and delete your
> vote.
>

Hi Zeev,

I think that this vote also makes sense for maintainers of  PECL extensions
as they will need to do lots of work.

I am aware what the patch does and how much work I will need to do in my
extensions. I actually did the openssl part of the 64bit patch just to see
what changes will be required for my crypto ext which also is an openssl
wrapper. And yes it will require lots of changes. Probably the most time
consuming part of the porting (that wasn't mentioned here) is looking to
the different versions of the libs and testing how it affects the
extension. There are sometimes types changes between different versions of
libs which can result in nasty bugs. For example the size_t change could
even result to some security issues if it's not handled properly.

The reason why I voted YES is that I don't see any difference if the patch
is merged now or in the future. The work will need to be done anyway. It
will just require more time that will need to be spent on maintaining the
64bit branch if the patch is merged later.

Thanks

Regards

Jakub

--001a11c2bd84c3680c04f15718b3--