From 1a02e2d367b71eca9fc8093ce83fcae50873003d Mon Sep 17 00:00:00 2001 From: Eric Wong Date: Fri, 3 Apr 2020 21:06:20 +0000 Subject: quiet "Complex regular subexpression recursion limit" warnings These seem mostly harmless since Perl will just truncate the match and start a new one on a newline boundary in our case. The only downside is we'd end up with redundant tags in HTML. Limiting the number of line matched ourselves with `{1,$NUM}' doesn't seem prudent since lines vary in length, so we continue to defer the job of limiting matches to the Perl regexp engine. I've noticed this warning in practice on 100K+ line patches to locale data. --- lib/PublicInbox/ViewDiff.pm | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'lib/PublicInbox/ViewDiff.pm') diff --git a/lib/PublicInbox/ViewDiff.pm b/lib/PublicInbox/ViewDiff.pm index d22c80b9..5d391a13 100644 --- a/lib/PublicInbox/ViewDiff.pm +++ b/lib/PublicInbox/ViewDiff.pm @@ -202,6 +202,17 @@ sub flush_diff ($$$) { $dctx = diff_header($dst, \$x, $ctx, \@top); } elsif ($dctx) { my $after = ''; + + # Quiet "Complex regular subexpression recursion limit" + # warning. Perl will truncate matches upon hitting + # that limit, giving us more (and shorter) scalars than + # would be ideal, but otherwise it's harmless. + # + # We could replace the `+' metacharacter with `{1,100}' + # to limit the matches ourselves to 100, but we can + # let Perl do it for us, quietly. + no warnings 'regexp'; + for my $s (split(/((?:(?:^\+[^\n]*\n)+)| (?:(?:^-[^\n]*\n)+)| (?:^@@ [^\n]+\n))/xsm, $x)) { -- cgit v1.2.3-24-ge0c7