Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71471
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.73.107 as permitted sender)
Message-ID: <33d0016a45c78b03e7a79fe85f11298b.squirrel@webmail.klapt.com>
In-Reply-To:
 <CADNQb0U+Re=KY18g970Uk31V8SEK5D8S1xU464bFScm7P_gU3g@mail.gmail.com>
References: <fa05c43bc2fff5420759e05dee19c99f.squirrel@webmail.klapt.com>
    <CAF+90c8mDBqe+E=cWxpD-U48Ho0QV3iHiwS9pOSEbUn_uZTVnQ@mail.gmail.com>
    <CA+9eiLvhRqFAunM8GCpqE5ja2jXKCzFMKdtF0NkBT11nu=36MQ@mail.gmail.com>
    <CAEZPtU7-mBoXcsvXQvD42uG58KKKLY3TJL=aV5uqcGEFhE3PKQ@mail.gmail.com>
    <CAEZPtU7vJDEyZAeCPR3j7_4+HL-4iCMUd3+Xa94xzg7xe1Z91Q@mail.gmail.com>
    <52E0F55F.4040802@lsces.co.uk>
    <CAF+90c8E6cKh7bt5KDdhxZso=sheNMGyLgdjA+9zckqoOL8jMg@mail.gmail.com>
    <2490044a0e2cba88044cf5da9b1b6647.squirrel@webmail.klapt.com>
    <CADNQb0U+Re=KY18g970Uk31V8SEK5D8S1xU464bFScm7P_gU3g@mail.gmail.com>
Date: Fri, 24 Jan 2014 03:42:47 +0100
To: "Hannes Magnusson" <hannes.magnusson@gmail.com>
Cc: "Anatol Belski" <ab@php.net>,
 "Nikita Popov" <nikita.ppv@gmail.com>,
 "Lester Caine" <lester@lsces.co.uk>,
 "PHP internals" <internals@lists.php.net>
Reply-To: "Anatol Belski" <ab@php.net>
User-Agent: SquirrelMail/1.5.2 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] 64 bit platform improvements for string length
 and integer
From: ab@php.net ("Anatol Belski")

Hi Hannes,

On Thu, January 23, 2014 19:38, Hannes Magnusson wrote:
> On Thu, Jan 23, 2014 at 9:52 AM, Anatol Belski <ab@php.net> wrote:
>
>
>>> If this patch is included in PHP 5.6 I think it is very likely that
>>> many extensions will not be updated or take a long while in updating.
>>> It's one
>>> thing to add two or three new ifdefs to support a new PHP release and
>>> something entirely else to change virtually all types in your code
>>> and verify that it is still safe with the new sizes.
>> I think it depends on how active an extension is supported and
>> developed. For instance on PECL are still some extensions not even been
>> ported to PHP5. From the todays experience, a port to the current patch
>> might take from 3 hours to 3 days, depending on complexity. Say 3 days
>> vs 5 months until final, together with the porting docs and tools, most
>> of the really active and being in demand extensions will be so far or
>> users will tear the devs apart :)
>>
>
>
> If zpp/error_docref/*printf compatibility is not kept it will take a
> long time to update pecl extensions, and risk epic failure in the future
> when continuing the work on the extensions
>
> zpp (COMPAT ? "zyx" : "xyz", &foo, &bar, &baz) will in 1year turn into zpp
> (COMPAT ? "zyx|xz" : "xyz|z", &foo, &bar, &baz, &meh) and work
> just fine.. until you hit the perfect storm
>
it's up to vote now, RFC updated (multiple votes in the same RFC). I've
prepared a change to zpp for any case http://pastie.org/8662202 .

The spprinf and derivatives - keeping %d working with real int and %ld
with real long looks unavoidable, as those will need to be used at some
places. Here the portable way would be still using ZEND_INT_FMT instead of
%pd and co. But this is actually primitive, like in vim

:%s,%ld," ZEND_INT_FMT ",g

Maybe some place will need to be cleaned after that, still it will do the
job.

>
> Its easy to migrate php-src exts since they don't have to care about
> compatibility with multiple php versions, but needing to support 5.3, 5.4,
> 5.5, 5.6, 5.7, 6.0 in a pecl extension will be nightmare
>
>
> Also, keep in mind most developers priority is not to work on
> supporting unreleased versions of PHP, but to keep maintaining the ext and
> adding features - so even though the guesstimate 5months "until final" is
> true, the extensions won't be updated until 5months _after_ 5.6.0 is out.
>
The compat issues between 5.4 and 5.5 are less than now. Even the amout of
breakage between 5.3 and 5.5 is less than now. However I'd really suggest
you to try the porting guide, if you couldn't get an average extension
compile in 1 hour or even less - too bad. Clear, some tricky places may
come after that, that's where one would need to spend more time than on
the routine "replace" task. Of course not talking about the calibre of
exts like ext\intl and similar, that's not an average case. From what I
saw now, the routine replacement task to just get an extension compiling
with older codebase might be 10-20% of the whole porting time. In some
cases it'll be everything one needs.

The routine is always annoying, that's true :) But it might be not the
worst issue one need to fix, if ever. I believe to have appropriately
reflected the current concerns with the voting options. So then the
direction of the porting process can be affected by everyone.


Regards

Anatol