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