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/MsgIter.pm | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'lib/PublicInbox/MsgIter.pm') diff --git a/lib/PublicInbox/MsgIter.pm b/lib/PublicInbox/MsgIter.pm index 6c18d2bf..fa25564a 100644 --- a/lib/PublicInbox/MsgIter.pm +++ b/lib/PublicInbox/MsgIter.pm @@ -71,4 +71,14 @@ sub msg_part_text ($$) { ($s, $err); } +# returns an array of quoted or unquoted sections +sub split_quotes { + # Quiet "Complex regular subexpression recursion limit" warning + # in case an inconsiderate sender quotes 32K of text at once. + # The warning from Perl is harmless for us since our callers can + # tolerate less-than-ideal matches which work within Perl limits. + no warnings 'regexp'; + split(/((?:^>[^\n]*\n)+)/sm, shift); +} + 1; -- cgit v1.2.3-24-ge0c7