After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 755693 - future of GRegex
future of GRegex
Product: glib
Classification: Platform
Component: gregex
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
: 782080 (view as bug list)
Depends on:
Reported: 2015-09-27 11:18 UTC by Christian Persch
Modified: 2018-05-24 18:14 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Christian Persch 2015-09-27 11:18:16 UTC
GLib uses PCRE for its regex support. There are a number of problems that need to be addressed:

* GLib embeds an old copy of PCRE; it needs to go away. This is already being discussed in bug 740573.

* GLib's PCRE support is at level of PCRE 8.31, a very old version, so it's missing the additions since then; bug 689791 is about updating it. And the corresponding wip/pcre-update branch is up to 8.35 (iirc?).

* GLib doesn't allow using PCRE's JIT which speeds up matching (bug 679155).

* PCRE itself is deprecated in favour of a new API called PCRE2. The old PCRE will only receive sporadic bugfix releases for a some time.

So there needs to be a fundamental decision about what to do with GRegex. I think these are the alternatives:

[A] (Least work) Deprecate GRegex (and perhaps later remove it) and recommend users to use PCRE2 directly.

[A'] Deprecate GRegex, drop PCRE use internally making GRegex a no-op (i.e. always return NULL and error from g_regex_new). Might be considered an ABI break.

[B] Update GRegex to use PCRE2 internally (and expose the JIT functionality).

[C] A and B.
Comment 1 Sébastien Wilmet 2015-09-27 14:26:52 UTC
Some applications and libraries in GNOME heavily use GRegex, like GtkSourceView for its syntax highlighting and search and replace.

Solution A', making GRegex a no-op, is clearly an API break and would break every module that uses GRegex. Backward compatibility is needed.
Comment 2 Michael Catanzaro 2016-01-05 00:27:13 UTC
I doubt there are going to be any objections to approach B.
Comment 3 Philip Withnall 2017-05-02 17:05:46 UTC
*** Bug 782080 has been marked as a duplicate of this bug. ***
Comment 4 GNOME Infrastructure Team 2018-05-24 18:14:32 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: