On 9 September 2015 at 03:42, Dmitry Stogov <dmi...@php.net> wrote: > Commit: ac83eaef1097552065395872c69b77dcab2919b1 > Author: Dmitry Stogov <dmi...@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? Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
