GNOME Bugzilla – Bug 767240
Regex failures with pcre 8.38
Last modified: 2016-08-16 08:42:47 UTC
I'm getting an error on make check - ERROR:regex.c:82:test_new: assertion failed (g_regex_get_compile_flags (regex) == data->real_compile_opts): (0x00000000 == 0x00000001) Looks like some options passed at the beginning of the regex pattern ("(?stuff)") are ignored. The following tests are failing. TEST_NEW_CHECK_FLAGS ("(?i)a", 0, 0, G_REGEX_CASELESS, 0); TEST_NEW_CHECK_FLAGS ("(?m)a", 0, 0, G_REGEX_MULTILINE, 0); TEST_NEW_CHECK_FLAGS ("(?s)a", 0, 0, G_REGEX_DOTALL, 0); TEST_NEW_CHECK_FLAGS ("(?x)a", 0, 0, G_REGEX_EXTENDED, 0); TEST_NEW_CHECK_FLAGS ("(?U)[a-z]+", 0, 0, G_REGEX_UNGREEDY, 0); This is using pcre on fedora 24.
The options are definitely not being ignored. pcre just stopped reporting them via the pcre_fullinfo() API.
This broke here, apparently somewhat intentionally: http://vcs.pcre.org/pcre/code/trunk/pcre_compile.c?r1=1616&r2=1617
imho, it's not really important that we report these options on the public API, and I don't see a good way of doing it with the currently-released PCRE. I think the correct fix here is a documentation tweak and removal of these testcases.
Created attachment 332992 [details] [review] gregex: loosen behaviour testing Circa 8.38, upstream PCRE (intentionally?) changed behaviour with respect to whether options set with expressions like "(?i)" at the top-level were reported via the pcre_fullinfo() API as having been requested during compilation. GLib contained a test that verified that these options were indeed reported as if they had been provided as flags on the API. Remove that check, and document the no-longer-deterministic behaviour.
The patch looks good to me, we don't have much choice to avoid the breakage if somebody relied these flags to be reported.
Pushed.