On Sep 16, 2015 8:08 AM, "Adam Harvey" <ahar...@php.net> wrote: > > 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?
I have to go with 3. It does not make a lot of sense to add APIs version for RC.
