Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71415
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52E01DDA.4020404@oracle.com>
References: <d27df615bc27d701daceb5ee605f540f.squirrel@webmail.klapt.com>
	<2ecdbcfc1725e25ccad4705429dbfa2f.squirrel@webmail.klapt.com>
	<52E01DDA.4020404@oracle.com>
Date: Wed, 22 Jan 2014 22:51:45 +0100
Message-ID: <CAEZPtU4KNm_hRKmveN7t2JGYd7s4=JnNvJ83Wr9pTUWdwzC+Cg@mail.gmail.com>
To: Christopher Jones <christopher.jones@oracle.com>
Cc: PHP internals <internals@lists.php.net>, Anatoliy Belsky <ab@php.net>
Content-Type: multipart/alternative; boundary=089e013d12d68752ec04f096215c
Subject: Re: [PHP-DEV] [RFC] 64 bit improvements, open questions
From: pierre.php@gmail.com (Pierre Joye)

--089e013d12d68752ec04f096215c
Content-Type: text/plain; charset=UTF-8

Hi Chris,

On Jan 22, 2014 8:37 PM, "Christopher Jones" <christopher.jones@oracle.com>
wrote:

> This is a huge patch - kudos.  However it will cause some short term
> instability.

If any instability it will be very quickly found.

> It's the kind of deep change that typically would be
> merged at the beginning, not the end, of a release process.

We are at the beginning.

> The new code will require time to stabilize.

It is actually very good, compare the tests results with other branches:

http://windows.php.net/downloads/snaps/ostc/pftt/STR_SIZE_AND_INT64/rfcb28ea/

> For example, there are
> some new OCI8 diffs that will require debugging.  There is one OCI8
> code block in PHP-5.6 that isn't in the str_size_and_int64 branch.

As Anatol asked many times, help is welcome. Which part is missing? In case
you cannot commit yourself.

> (I'll send details separately).  It's likely other extensions will be
> similarly subtly impacted.
>
> The open issues (e.g. SAPI support) need to be resolved before
> starting the vote, so the RFC direction is obvious.

All active and maintained SAPIs are supported. Porting dead cows is not
worth the effort.

>  Also the RFC
> needs to discuss proposed voting options, prior to starting the vote.

> Since that only gives a couple of days for discussion, I think you
> should delay the vote.

Well, it has been under discussions for quite some time already. The open
questions (to be chosen) are known. Did we forget something?

Thanks for your feedback!

Cheers,
Pierre

--089e013d12d68752ec04f096215c--