# [RFC] PCRE2 migration - Thread: https://externals.io/message/100905 - Original archive: https://news-web.php.net/php.internals/100905 - Started by Anatol Belski on 2017-10-16T08:17:02+00:00 - Messages: 9 - RFC: PCRE2 Migration (Implemented (PHP 7.3)) — https://externals.io/rfc/pcre2-migration.md - 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 --- ## #100905 — Anatol Belski — 2017-10-16T08:17:02+00:00 URL: https://externals.io/message/100905#100905 Hi, I would like hereby to put the RFC about the PCRE2 migration for the core https://wiki.php.net/rfc/pcre2-migration under discussion. A basic port is available here https://github.com/php/php-src/pull/2857 for a review. Regards Anatol --- ## #100915 — Anatol Belski — 2017-10-23T05:34:28+00:00 URL: https://externals.io/message/100905#100915 · In reply to: #100905 Hi, > Hi, > > I would like hereby to put the RFC about the PCRE2 migration for the > core https://wiki.php.net/rfc/pcre2-migration under discussion. A basic > port is available here https://github.com/php/php-src/pull/2857 for a > review. > poke on this :) Regards Anatol --- ## #100916 — Christoph M. Becker — 2017-10-23T14:23:57+00:00 URL: https://externals.io/message/100905#100916 · In reply to: #100905 > I would like hereby to put the RFC about the PCRE2 migration for the > core https://wiki.php.net/rfc/pcre2-migration under discussion. A basic > port is available here https://github.com/php/php-src/pull/2857 for a > review. Thanks, Anatol, for working on a PCRE2 compatible ext/pcre! In my opinion, the only real issue is that the internal API would change (the few userland affecting changes appear to be acceptable). I can't assess how many extensions actually use the public API of ext/pcre, but this might be an issue regarding the adoption of PHP 7.3. This said, I'm presently +0.9 on accepting the RFC. -- Christoph M. Becker --- ## #100917 — Anatol Belski — 2017-10-23T20:12:15+00:00 URL: https://externals.io/message/100905#100917 · In reply to: #100916 Hi Christoph, > -----Original Message----- > From: Christoph M. Becker [mailto:cmbecker69@gmx.de] > Sent: Monday, October 23, 2017 4:24 PM > To: Anatol Belski ; internals@lists.php.net > Subject: Re: [RFC] PCRE2 migration > > In my opinion, the only real issue is that the internal API would change (the few > userland affecting changes appear to be acceptable). I can't assess how many > extensions actually use the public API of ext/pcre, but this might be an issue > regarding the adoption of PHP 7.3. > Some exts use PCRE or the PHP API, of course. From what I've seen so far - The migration is easy, despite the PCRE2 API is somewhat different. If asked, I could help patching any code for PCRE2 support. - there's time to rework the API as in the patch, some points can be changed significantly - From what I could tell, the ratio of PECL exts using PCRE is low. In fact, I can't remember any, OFC there are be some. > This said, I'm presently +0.9 on accepting the RFC. > PCRE2 implements new features and fixes issues, while the legacy version only gets backports which are not optimal. At the time after two years PCRE2 release and the situation with PCRE support, switching seems a thing to me. The existing features are not broken, better Unicode support and improvements in functionality and memory handling speak for that. Regards Anatol --- ## #100918 — Jakub Zelenka — 2017-10-23T20:42:31+00:00 URL: https://externals.io/message/100905#100918 · In reply to: #100905 Hey > Hi, > > I would like hereby to put the RFC about the PCRE2 migration for the > core https://wiki.php.net/rfc/pcre2-migration under discussion. A basic > port is available here https://github.com/php/php-src/pull/2857 for a > review. > > Sorry if that's a stupid question and I'm missing something important but why do we need to still bundle PCRE2? Cheers Jakub --- ## #100919 — Anatol Belski — 2017-10-23T21:07:08+00:00 URL: https://externals.io/message/100905#100919 · In reply to: #100918 Hi Jakub, > -----Original Message----- > From: jakub.php@gmail.com [mailto:jakub.php@gmail.com] On Behalf Of Jakub > Zelenka > Sent: Monday, October 23, 2017 10:43 PM > To: Anatol Belski > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] PCRE2 migration > > Hey > > > On Mon, Oct 16, 2017 at 9:17 AM, Anatol Belski > wrote: > > > Hi, > > I would like hereby to put the RFC about the PCRE2 migration for the > core https://wiki.php.net/rfc/pcre2-migration > under discussion. A basic > port is available here https://github.com/php/php-src/pull/2857 > for a > review. > > > > > Sorry if that's a stupid question and I'm missing something important but why do > we need to still bundle PCRE2? > I ask such questions just for the fun of it all the time, that makes sense to my character 😊 The point of the RFC is the max BC. Currently PCRE is bundled. Otherwise, the lib is essential for the core and thus needs to be always available. For older distro versions like for example Debian Jessie or other OSes not yet providing PCRE2 from the package management, that would be the only way to get a newer PHP version, even if compiled by hand. Except maybe when libpcre2 were provided by a third party repo, or a PPA in the Debian terminology. Another point on that is, even if a package is available on the target platform - the bundled version is what is tested and highly recommended. Builders can decide otherwise, but what we provide makes the point. Lately, for example - the valgrind support is also essential, as a release version supplied by a distro likely wouldn't be built with valgrind support but it's required to debug PHP issues. Otherwise, there's no need for bundling. This dependency is currently not patched in the way it would be the only one to be required bundled. It is simply handy to have it bundled for the development and compatibility. Any distribution can decide, whether they would use it bundled or external. Regards Anatol --- ## #100932 — Jakub Zelenka — 2017-10-24T13:53:55+00:00 URL: https://externals.io/message/100905#100932 · In reply to: #100919 > Hi Jakub, > > > […] > Jakub > > […] > the > > […] > but why do > > […] > I ask such questions just for the fun of it all the time, that makes sense > to my character 😊 > > The point of the RFC is the max BC. Currently PCRE is bundled. Otherwise, > the lib is essential for the core and thus needs to be always available. > For older distro versions like for example Debian Jessie or other OSes not > yet providing PCRE2 from the package management, that would be the only way > to get a newer PHP version, even if compiled by hand. Except maybe when > libpcre2 were provided by a third party repo, or a PPA in the Debian > terminology. > > Another point on that is, even if a package is available on the target > platform - the bundled version is what is tested and highly recommended. > Builders can decide otherwise, but what we provide makes the point. Lately, > for example - the valgrind support is also essential, as a release version > supplied by a distro likely wouldn't be built with valgrind support but > it's required to debug PHP issues. > > Otherwise, there's no need for bundling. This dependency is currently not > patched in the way it would be the only one to be required bundled. It is > simply handy to have it bundled for the development and compatibility. Any > distribution can decide, whether they would use it bundled or external. > Well I think that all listed reasons for bundling could be applied to other libraries. For example we won't start bundling OpenSSL just because we won't to make the new functionality easily available. The debugging point can be also true there because distros won't ship version configured with -d. However one can easily compile the library in that way so I don't see it as a problem at all. Personally I'm not a big fan of bundling libraries unless there is some technical reason to do so (for example an unexposed API that is necessary for inner working of the extension). The number of PCRE2 releases and its size is of course much smaller than for example mentioned OpenSSL but it still seems a bit unnecessary to me. Anyway this is something that can be discussed separately as we already bundle PCRE so this is just a bundle replacement that actually reduces the number of bundled lines... :) Cheers Jakub --- ## #100937 — Anatol Belski — 2017-10-24T18:39:30+00:00 URL: https://externals.io/message/100905#100937 · In reply to: #100932 Hi Jakub, > -----Original Message----- > From: jakub.php@gmail.com [mailto:jakub.php@gmail.com] On Behalf Of Jakub > Zelenka > Sent: Tuesday, October 24, 2017 3:54 PM > To: Anatol Belski > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] PCRE2 migration > > > > On Mon, Oct 23, 2017 at 10:07 PM, Anatol Belski > wrote: > > > Hi Jakub, > > > […] > [mailto:jakub.php@gmail.com ] On Behalf Of > Jakub > > […] > > > […] > the > > […] > > > […] > > under discussion. A basic > > […] > > > […] > > for a > > […] > but why do > > […] > I ask such questions just for the fun of it all the time, that makes sense > to my character 😊 > > The point of the RFC is the max BC. Currently PCRE is bundled. > Otherwise, the lib is essential for the core and thus needs to be always available. > For older distro versions like for example Debian Jessie or other OSes not yet > providing PCRE2 from the package management, that would be the only way to > get a newer PHP version, even if compiled by hand. Except maybe when libpcre2 > were provided by a third party repo, or a PPA in the Debian terminology. > > Another point on that is, even if a package is available on the target > platform - the bundled version is what is tested and highly recommended. > Builders can decide otherwise, but what we provide makes the point. Lately, for > example - the valgrind support is also essential, as a release version supplied by > a distro likely wouldn't be built with valgrind support but it's required to debug > PHP issues. > > > > Otherwise, there's no need for bundling. This dependency is currently > not patched in the way it would be the only one to be required bundled. It is > simply handy to have it bundled for the development and compatibility. Any > distribution can decide, whether they would use it bundled or external. > > > > > Well I think that all listed reasons for bundling could be applied to other libraries. > For example we won't start bundling OpenSSL just because we won't to make > the new functionality easily available. The debugging point can be also true > there because distros won't ship version configured with -d. However one can > easily compile the library in that way so I don't see it as a problem at all. > Personally I'm not a big fan of bundling libraries unless there is some technical > reason to do so (for example an unexposed API that is necessary for inner > working of the extension). The number of PCRE2 releases and its size is of > course much smaller than for example mentioned OpenSSL but it still seems a bit > unnecessary to me. > That's true, one could create a custom libpcre2 build with valgrind support to link externally. But, it's not about just debug build or symbols, JIT compiled patterns are a self-modifying code, valgrind enabled tests would not get it right without a special valgrind integration. Almost needed for dev and bug fixing. > > Anyway this is something that can be discussed separately as we already bundle > PCRE so this is just a bundle replacement that actually reduces the number of > bundled lines... :) > Yeah, the RFC's approach is to have same status as it is now, but with PCRE2 instead of PCRE. More like about solving the principal question than going into further details. Regards Anatol --- ## #100940 — Christoph M. Becker — 2017-10-25T15:55:19+00:00 URL: https://externals.io/message/100905#100940 · In reply to: #100917 Hi Anatol! > > […] > > Some exts use PCRE or the PHP API, of course. From what I've seen so far > > - The migration is easy, despite the PCRE2 API is somewhat different. If asked, I could help patching any code for PCRE2 support. > - there's time to rework the API as in the patch, some points can be changed significantly > - From what I could tell, the ratio of PECL exts using PCRE is low. In fact, I can't remember any, OFC there are be some. Well, that sounds good. :) And yes, I'm aware that upgrading to PCRE2 is actually long overdue, so +1 from me. -- Christoph M. Becker