ABI break? (was: [PHP-CVS] com php-src: Don't inline "slow" and rarely used functions.: Zend/zend_alloc.c Zend/zend_alloc.h)

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=php-src.git;a=commitdiff;h=ac83eaef1097552065395872c69b77dcab2919b1

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 — avoiding this kind of thing is why
we have API versioning!). Dmitry, RMs: what are your thoughts?

I have to go with 3. It does not make a lot of sense to add APIs version
for RC.

Hi Adam,

-----Original Message-----
From: adam@adamharvey.name [mailto:adam@adamharvey.name] On Behalf
Of Adam Harvey
Sent: Wednesday, September 16, 2015 3:08 AM
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
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)

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=php-
src.git;a=commitdiff;h=ac83eaef1097552065395872c69b77dcab2919b1

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 — avoiding this kind of thing is why we have API versioning!).
Dmitry, RMs: what are your thoughts?

While your observation is correct, I wouldn't see the matter as an alarming issue. We're oriented to have less bugs in every next RC, thus RC2 will have had its day soon anyway. So IMHO this change is not quite nice at this stage, but still acceptable.

Regards

Anatol