Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88223
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.215.53 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
Date: Tue, 15 Sep 2015 18:07:54 -0700
Message-ID: <CADajX4Du43JtWGGKURsQWxM7CZs6+3yv+0L1uJVnZr9cV5Ct1w@mail.gmail.com>
To: Dmitry Stogov <dmitry@php.net>
Cc: PHP internals <internals@lists.php.net>, Anatoliy Belsky <ab@php.net>, 
	Kalle Sommer Nielsen <kalle@php.net>, Ferenc Kovacs <tyrael@php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: ABI break? (was: [PHP-CVS] com php-src: Don't inline "slow" and
 rarely used functions.: Zend/zend_alloc.c Zend/zend_alloc.h)
From: aharvey@php.net (Adam Harvey)

On 9 September 2015 at 03:42, Dmitry Stogov <dmitry@php.net> wrote:
> Commit:    ac83eaef1097552065395872c69b77dcab2919b1
> Author:    Dmitry Stogov <dmitry@zend.com>         Wed, 9 Sep 2015 13:42:=
35 +0300
> Parents:   6d885e395ca33fef28c5b84b7cfd59885aaa6e2d
> Branches:  master
>
> Link:       http://git.php.net/?p=3Dphp-src.git;a=3Dcommitdiff;h=3Dac83ea=
ef1097552065395872c69b77dcab2919b1
>
> Log:
> Don't inline "slow" and rarely used functions.

This commit appears to have broken binary compatibility for extensions
that make persistent memory allocations, since __zend_malloc is now a
real function and not inlined: such an extension compiled against
php-src after this commit can no longer be loaded into earlier builds
due to the missing __zend_malloc symbol.

Most current extensions with PHP 7 compatibility aren't affected, but
the one relatively common case where a persistent allocation occurs is
when defining classes: INIT_CLASS_ENTRY() ultimately expands to
INIT_OVERLOADED_CLASS_ENTRY_EX(), which calls zend_string_init() with
the persistent flag enabled to create the class name string.

It's awkward, since PHP 7.0 hasn't officially been released yet, but
it sucks that some extensions won't be binary compatible between RC2
and RC3 (as things stand today). Options, as I see it:

1. Revert this commit.
2. Bump the extension API number.
3. Document that binary compatibility was broken in RC3, and that we
don't guarantee binary compatibility before a stable release is made.

I personally don't think option 3 is viable (yes, it's not a stable
release, but it's still crappy =E2=80=94 avoiding this kind of thing is _wh=
y_
we have API versioning!). Dmitry, RMs: what are your thoughts?

Adam