Hi Nikita, > -----Original Message----- > From: Nikita Popov [mailto:nikita....@gmail.com] > Sent: Sunday, July 23, 2017 12:52 PM > To: Sara Golemon <poll...@php.net> > Cc: PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] PHP 7.2 forked > > On Sun, Jul 23, 2017 at 3:55 AM, Sara Golemon <poll...@php.net> wrote: > > > On Sat, Jul 22, 2017 at 12:48 PM, Nikita Popov <nikita....@gmail.com> > > wrote: > > > What's out current state regarding ABI? I've recently done some work > > > on making mbstring slightly less abysmally slow, but landed the > > > changes on master only, because this included ABI breaks in > > > mbfl/mbstring APIs and globals. Is this something I can land in > > > PHP-7.2, or is it closed to extension ABI changes? > > > > > During beta I'm willing to tolerate some ABI breaks for high-value > > things, but while mbstring performance is inarguably a good thing, > > stability is an even better thing. Anatol mentioned concern about > > stability, ergo I'm inclined to defer these improvements till 7.3. > > > > -Sara > > > > What Anatol is probably referring to here is that next to the performance > improvements, the mbstring extension has also been migrated to use size_t > instead of int lengths. This is something we originally overlooked during the > size_t port in PHP 7. This is a major change and its easy to overlook > something, > so the concern for stability is well justified. Conversely, this does also > fix a range > of length overflow related bugs (I have manually verified this on a sample of > related bug reports). > Ok, so seems I mistook the intention then and you were referring to these only (or at least)
http://git.php.net/?p=php-src.git;a=commitdiff;h=dead4f0b1b9a555bbea970f5399c01142414db85 http://git.php.net/?p=php-src.git;a=commitdiff;h=4cf22cbb2d3b777cceb0087cdfd2a571aaf76850 http://git.php.net/?p=php-src.git;a=commitdiff;h=4128746b949355f588143ef18ad98fdfda089873 http://git.php.net/?p=php-src.git;a=commitdiff;h=9c73be898d4e5aa2e64b21da14797ec9ad202134 http://git.php.net/?p=php-src.git;a=commitdiff;h=79c26d597fd8245c30ee74faf05b8d6f9ece3fef That's indeed a different matter. Some indeed contain minimal API breach. In some case it could be reduced by keeping the old symbol unchanged while introducing a new one. For example `php_unicode_is_prop` could be kept, but the other new one could be `php_unicode_is_prop_va`. Leaving the size_t patches for master only, the breach is minimal and could be even yet more minimized. Sara, if this sounds manageable to you, perhaps you could still consider to evaluate the subset only, perhaps on a dedicated patch. Regards Anatol
