GNOME Bugzilla – Bug 755693
future of GRegex
Last modified: 2018-05-24 18:14:32 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.
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.
I doubt there are going to be any objections to approach B.
*** Bug 782080 has been marked as a duplicate of this bug. ***
-- 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: https://gitlab.gnome.org/GNOME/glib/issues/1085.