Hi Adam, > -----Original Message----- > From: a...@adamharvey.name [mailto:a...@adamharvey.name] On Behalf > Of Adam Harvey > Sent: Wednesday, September 16, 2015 3:08 AM > To: Dmitry Stogov <dmi...@php.net> > Cc: PHP internals <internals@lists.php.net>; Anatoliy Belsky <a...@php.net>; > Kalle > Sommer Nielsen <ka...@php.net>; Ferenc Kovacs <tyr...@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) > > 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? > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
