Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71455
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.10.1401231236330.6067@whisky.home.derickrethans.nl>
References: <d27df615bc27d701daceb5ee605f540f.squirrel@webmail.klapt.com>
	<52E063B4.9000100@oracle.com>
	<alpine.DEB.2.10.1401231236330.6067@whisky.home.derickrethans.nl>
Date: Thu, 23 Jan 2014 20:13:31 +0100
Message-ID: <CAEZPtU7=_GjhMjDjOBBOJYRfqX=V1N=eGZ2d=zLjdBAVwkxsDg@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: Christopher Jones <christopher.jones@oracle.com>, Anatol Belski <ab@php.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] 64 bit improvements, open questions
From: pierre.php@gmail.com (Pierre Joye)

On Thu, Jan 23, 2014 at 12:38 PM, Derick Rethans <derick@php.net> wrote:
> On Wed, 22 Jan 2014, Christopher Jones wrote:
>
>> On 01/22/2014 12:20 AM, Anatol Belski wrote:
>> >
>> > as the discussion phase for this RFC nears to the finish and the
>> > patch itself is huge, I'd like to use the last chance to discuss the
>> > open questions and concerns. Here are once more the links to the RFC
>> > (with several updates) and the porting guide
>> >
>> > https://wiki.php.net/rfc/size_t_and_int64
>> > http://git.php.net/?p=3Dphp-src.git;a=3Dblob;f=3Dcompat/PECL_PORTING;h=
b=3Drefs/heads/str_size_and_int64
>> >
>> > The big open question from the previous discussion is how to handle
>> > changed ZPP formats. The way I've suggested in the porting doc is
>> > using ternary operator like (COMP ? "l" : "i"). Another way were to
>> > put the old ZPP formats "lLsp" back and make them redundant to the
>> > new ones "iISP". Both ways have their pro and contra, the second
>> > variant isn't done, but can be done quickly.
>>
>> With 22 lines of compatibility macros borrowed from compat/compat.h, I
>> can make the "size_t_and_int64" branch of OCI8 compile with PHP
>> 5.5. Making ZPP call changes to fix the formats would give a very much
>> fuglier code base.  There are 86 calls to ZPP in OCI8 (not all would
>> need changing).
>
> That would make me a sad panda, I mean, having to #ifdef lots of ZPP
> calls. Please try to avoid this necessity. As the 64-bit branch is
> really most important for the Windows port=E2=80=94most Unix-like users r=
un on
> 64-bit already anyway=E2=80=94the difficulty of supporting it should not =
be
> pushed on already existing extensions.

Yes, that's one of the open questions.

I think we can solve the zpp issue by using the same. However some
changes will be required and should be BC, especially for size_t, as
we really have to use it. I am not sure yet about the int64 usage vs
long without too much impact. It is especially important as long usage
is really not the way to go.

It is also very important to keep in mind that this patch is not only
about improving windows 64bits support, there is much more behind
that. Get rid of int for buffer size, right usage of 64bit integers,
it will drastically reduce the 64bit bugs (security one included).

Also about the PECL extensions problem, no matter which solution is
chosen, it is really easy to port them. The "people won't be able to
use pecl exts because they are not available" argument is somehow
pointless. If maintainers do not port their extension to the latest
PHP version within a couple of months after its release, or even
during the release phases, they won't do it for the next version
either. We can't delay a change forever because of them. Also my
experience is that most used and maintained extensions are ported very
quickly, during the release phases. Dead cows remain dead.

Cheers,
--
Pierre

@pierrejoye | http://www.libgd.org