# PHP 7.2 forked

- Thread: https://externals.io/message/99903
- Original archive: https://news-web.php.net/php.internals/99903
- Started by Sara Golemon on 2017-07-18T14:48:16+00:00
- Messages: 13
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #99903 — Sara Golemon — 2017-07-18T14:48:16+00:00

URL: https://externals.io/message/99903#99903

That's it! Feature freeze is on.

Please include branch PHP-7.2 in all merges from 7.1 and earlier.
Please commit all 7.2 fixes to PHP-7.2 and merge to master which is
now targetting 7.3

This is real. https://github.com/php/php-src/commit/5230541ef59e0637d5522293a7d099bf18ce6af3

-Sara

---

## #99907 — Jan Ehrhardt — 2017-07-18T17:11:19+00:00

URL: https://externals.io/message/99903#99907 · In reply to: #99903

Sara Golemon in php.internals (Tue, 18 Jul 2017 10:48:16 -0400):
>That's it! Feature freeze is on.

Congrats. Question, maybe for Anatol: what did change in the Windows
Build environment? It was taking ages for 'Generating code', for each
extension. Now it is as fast as building PHP 7.1.
-- 
Jan

---

## #99932 — Anatol Belski — 2017-07-19T13:37:59+00:00

URL: https://externals.io/message/99903#99932 · In reply to: #99907

Hi Jan,

> -----Original Message-----
> From: Jan Ehrhardt [mailto:phpdev@ehrhardt.nl]
> Sent: Tuesday, July 18, 2017 7:11 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] Re: PHP 7.2 forked
> 
> Sara Golemon in php.internals (Tue, 18 Jul 2017 10:48:16 -0400):
> > […]
> 
> Congrats. Question, maybe for Anatol: what did change in the Windows Build
> environment? It was taking ages for 'Generating code', for each extension. Now
> it is as fast as building PHP 7.1.
> --
There is no change in the build process, disregarding the requirement on the new SDK. The build efficiency usually depends on the power of the build host. What I can only guess, is that the removal of /LTCG for non PGO build could improve build speed on a less powerful machine. That option was added in master, but had to be removed due to compatibility issues.

Regards

Anatol

---

## #99936 — Jan Ehrhardt — 2017-07-19T15:47:26+00:00

URL: https://externals.io/message/99903#99936 · In reply to: #99932

Hi Anatol.

Anatol Belski in php.internals (Wed, 19 Jul 2017 13:37:59 +0000):
>Hi Jan,
>
> > […]
>
>There is no change in the build process, disregarding the requirement on
>the new SDK. The build efficiency usually depends on the power of the
>build host. What I can only guess, is that the removal of /LTCG for non
>PGO build could improve build speed on a less powerful machine. That
>option was added in master, but had to be removed due to compatibility
>issues.

The difference was very substantial on my Lenovo X220 with an Intel Core
i7 2620M (2.7GHz). Of course, I was already using the new SDK.
-- 
Jan

---

## #100013 — Nikita Popov — 2017-07-22T16:48:06+00:00

URL: https://externals.io/message/99903#100013 · In reply to: #99903

> That's it! Feature freeze is on.
>
> Please include branch PHP-7.2 in all merges from 7.1 and earlier.
> Please commit all 7.2 fixes to PHP-7.2 and merge to master which is
> now targetting 7.3
>
> This is real. https://github.com/php/php-src/commit/
> 5230541ef59e0637d5522293a7d099bf18ce6af3
>
> -Sara
>

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?

Nikita

---

## #100014 — Kalle Sommer Nielsen — 2017-07-22T17:19:01+00:00

URL: https://externals.io/message/99903#100014 · In reply to: #100013

2017-07-22 18:48 GMT+02:00 Nikita Popov <nikita.ppv@gmail.com>:
> 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?

afair ABI can be broken until a branch/release hits RC, after that its
on case by case basis



-- 
regards,

Kalle Sommer Nielsen
kalle@php.net

---

## #100016 — Anatol Belski — 2017-07-22T23:18:57+00:00

URL: https://externals.io/message/99903#100016 · In reply to: #100013

Hi Nikita,

> -----Original Message-----
> From: Nikita Popov [mailto:nikita.ppv@gmail.com]
> Sent: Saturday, July 22, 2017 6:48 PM
> To: Sara Golemon <pollita@php.net>
> Cc: PHP internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] PHP 7.2 forked
> 
> 
> 
> > […]
> 
> 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?
> 
I was checking the patch so far, frankly I'm not sure how stable it is yet. But if RMs accept it, I think quite some stress test should be done. Anyway, as libmbfl doesn't seem to be active for long, patching it for better compatibility seems a right step.

Regards

Anatol

---

## #100017 — Sara Golemon — 2017-07-23T01:55:47+00:00

URL: https://externals.io/message/99903#100017 · In reply to: #100013

> 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

---

## #100018 — Nikita Popov — 2017-07-23T10:52:13+00:00

URL: https://externals.io/message/99903#100018 · In reply to: #100017

> On Sat, Jul 22, 2017 at 12:48 PM, Nikita Popov <nikita.ppv@gmail.com>
> wrote:
> > […]
> 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).

Nikita

---

## #100019 — Anatol Belski — 2017-07-23T11:58:36+00:00

URL: https://externals.io/message/99903#100019 · In reply to: #100018

Hi Nikita,

> -----Original Message-----
> From: Nikita Popov [mailto:nikita.ppv@gmail.com]
> Sent: Sunday, July 23, 2017 12:52 PM
> To: Sara Golemon <pollita@php.net>
> Cc: PHP internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] PHP 7.2 forked
> 
> 
> 
> > […]
> 
> 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

---

## #100022 — Sara Golemon — 2017-07-23T19:19:04+00:00

URL: https://externals.io/message/99903#100022 · In reply to: #100019

> 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
>
Yeah, go ahead and put those on 7.2

-Sara

---

## #100044 — Nikita Popov — 2017-07-26T12:48:25+00:00

URL: https://externals.io/message/99903#100044 · In reply to: #100022

> On Sun, Jul 23, 2017 at 7:58 AM, Anatol Belski <weltling@outlook.de>
> wrote:
> > […]
> these only (or at least)
> > […]
> dead4f0b1b9a555bbea970f5399c01142414db85
> > […]
> 4cf22cbb2d3b777cceb0087cdfd2a571aaf76850
> > […]
> 4128746b949355f588143ef18ad98fdfda089873
> > […]
> 9c73be898d4e5aa2e64b21da14797ec9ad202134
> > […]
> 79c26d597fd8245c30ee74faf05b8d6f9ece3fef
> > […]
> Yeah, go ahead and put those on 7.2
>
> -Sara
>

I've decided to leave all the changes to master only. At this point there
are so many entangled changes that I don't think a partial backport is
worthwhile. Some of the more important changes happened after the size_t
and no_encoding ports, so applying them to 7.2 without the other
refactoring would take additional work.

Nikita

---

## #100045 — Anatol Belski — 2017-07-26T12:51:53+00:00

URL: https://externals.io/message/99903#100045 · In reply to: #100044

> -----Original Message-----
> From: Nikita Popov [mailto:nikita.ppv@gmail.com]
> Sent: Wednesday, July 26, 2017 2:48 PM
> To: Sara Golemon <pollita@php.net>
> Cc: Anatol Belski <weltling@outlook.de>; PHP internals
> <internals@lists.php.net>
> Subject: Re: [PHP-DEV] PHP 7.2 forked
> 
> On Sun, Jul 23, 2017 at 9:19 PM, Sara Golemon <pollita@php.net
> <mailto:pollita@php.net> > wrote:
> 
> 
> 	On Sun, Jul 23, 2017 at 7:58 AM, Anatol Belski <weltling@outlook.de
> <mailto:weltling@outlook.de> > wrote:
> > […]
> these only (or at least)
> > […]
> src.git;a=commitdiff;h=dead4f0b1b9a555bbea970f5399c01142414db85
> <http://git.php.net/?p=php-
> src.git;a=commitdiff;h=dead4f0b1b9a555bbea970f5399c01142414db85>
> > […]
> src.git;a=commitdiff;h=4cf22cbb2d3b777cceb0087cdfd2a571aaf76850
> <http://git.php.net/?p=php-
> src.git;a=commitdiff;h=4cf22cbb2d3b777cceb0087cdfd2a571aaf76850>
> > […]
> src.git;a=commitdiff;h=4128746b949355f588143ef18ad98fdfda089873
> <http://git.php.net/?p=php-
> src.git;a=commitdiff;h=4128746b949355f588143ef18ad98fdfda089873>
> > […]
> src.git;a=commitdiff;h=9c73be898d4e5aa2e64b21da14797ec9ad202134
> <http://git.php.net/?p=php-
> src.git;a=commitdiff;h=9c73be898d4e5aa2e64b21da14797ec9ad202134>
> > […]
> src.git;a=commitdiff;h=79c26d597fd8245c30ee74faf05b8d6f9ece3fef
> <http://git.php.net/?p=php-
> src.git;a=commitdiff;h=79c26d597fd8245c30ee74faf05b8d6f9ece3fef>
> > […]
> 	Yeah, go ahead and put those on 7.2
> 
> 	-Sara
> 
> 
> 
> I've decided to leave all the changes to master only. At this point there are so
> many entangled changes that I don't think a partial backport is worthwhile.
> Some of the more important changes happened after the size_t and
> no_encoding ports, so applying them to 7.2 without the other refactoring would
> take additional work.
> 
ACK, I'll put #74929 into the master news and close it.

Regards

Anatol
