GNOME Bugzilla – Bug 679193
update included pcre to 8.31
Last modified: 2012-07-07 20:08:23 UTC
This is mostly a minor update. The unicode 6.1 update is now upstream reducing our diff to upstream; the rest is mostly bug fixes (and JIT improvements, so this is a prereq for bug 679155). There's just one bit of new API we want to expose. I've pushed a wip/pcre-8.31 branch that contains the update to 8.31-RC2, so this can be reviewed now. The commit will of course wait for the 8.31 final being released. The code drop is http://git.gnome.org/browse/glib/commit/?h=wip/pcre-8.31&id=2e137e6899b7a7c33b2bea81d4080338b258074b ; I'm going to attach the rest here.
Created attachment 217723 [details] [review] regex: Enable fixed test This problem was fixed in PCRE 8.31, so uncomment the test.
Created attachment 217724 [details] [review] regex: Add new GRegexError code from PCRE 8.31
Created attachment 217725 [details] [review] regex: Add accessor to get max length of lookbehind characters Use PCRE_INFO_MAXLOOKBEHIND to get the length (in characters) of the longest lookbehind assertion in the pattern.
Review of attachment 217723 [details] [review]: ok
Review of attachment 217724 [details] [review]: ok
Review of attachment 217725 [details] [review]: ::: glib/gregex.c @@ +1527,3 @@ + +/** Unnecessary extra newline there @@ +1532,3 @@ + * + * Returns the lentgh of the longest lookbehind assertion in the pattern, in + * characters. Returns <literal>0</literal> if the pattern does not No need for <literal> here, we generally just leave numbers undecorated in text @@ +1537,3 @@ + * This information may be useful when doing incremental partial matching; in + * that case you should always keep at least this many characters before the + * partially matched string. This is useful documentation - it would be good to xref this from the partial matching flags documentation, maybe.
Thanks for all the work you are putting into GRegex, btw. Much appreciated.
PCRE 8.31 has been released; ok to commit this patch series? (Minus the last patch, attachment 217725 [details] [review]. I've fixed the things you pointed out in it, but it turns out that gregex doesn't allow doing this incremental ('multi-segmented' in man:pcrepartial(3) ) partial matching since there's no way to fetch the position of the start of the partial match. And without that g_regex_get_max_lookbehind() doesn't have a use case. So I'll move that to a separate bug.)
sure, sounds good