Bug#1118572: libpcre2-8-0: pcre2 10.47 behaviour change: different error for ^(a)\g{3

Matthew Vernon matthew at debian.org
Wed Oct 22 11:29:54 BST 2025


Hi,

> ...
> not ok /regex/new-fail/78 - ERROR:../../../glib/tests/regex.c:133:test_new_fail: assertion failed (error == (g-regex-error-quark, 157)): Error while compiling regular expression ?^(a)\g{3? at char 8: syntax error in subpattern number (missing terminator?) (g-regex-error-quark, 0)
> Bail out!
> Aborted                    (core dumped) /usr/libexec/installed-tests/glib/regex
> 134
> 
> I'm reasonably sure this would also make glib2.0 FTBFS (hence the ftbfs
> tag) although I haven't verified this.

Yes, it does (per debusine).
> The test failure is that GLib is expecting that compiling the
> (incomplete) regex "(a)\g{3" will produce PCRE2_ERROR_BACKSLASH_G_SYNTAX
> (which it translates to GRegexError number 157,
> G_REGEX_ERROR_MISSING_BACK_REFERENCE), but in fact it saw some error code
> that is not specifically handled by translate_compile_error() in
> glib/gregex.c, resulting in the default error, G_REGEX_ERROR_COMPILE.
> 
> Was this an intentional behaviour change in PCRE?

Yes, part of https://github.com/PCRE2Project/pcre2/pull/756/

If you look at the changes to testdata/testoutput2 you'll see at lines 
7855 and 7855 that the error number and text for
/^(a)\g{3/

have changed from:
Failed: error 157 at offset 6: \g is not followed by a braced, 
angle-bracketed, or quoted name/number or by a plain number
         here: ^(a)\g |<-->| {3

to:
Failed: error 219 at offset 8: syntax error in subpattern number 
(missing terminator?)
         here: ^(a)\g{3 |<--|Because there's a new and more-specific 
error code PCRE2_ERROR_MISSING_NUMBER_TERMINATOR

in the error case that was previously just handled as 
PCRE2_ERROR_BACKSLASH_G_SYNTAX So I think this will need fixing in the 
glib2 build-time test suite?
Regards,

Matthew



More information about the pkg-gnome-maintainers mailing list