[webkit-reviews] review requested: [Bug 50816] REGRESSION: Hang inside Yarr::RegexCodeBlock::execute when visiting bugs.webkit.org : [Attachment 76294] Updated Patch to handle the first nested paren, not just when the first nested term is a paren

[bugzilla-daemon at webkit.org]

Michael Saboff <msaboff at apple.com> has asked  for review:
Bug 50816: REGRESSION: Hang inside Yarr::RegexCodeBlock::execute when visiting
bugs.webkit.org
https://bugs.webkit.org/show_bug.cgi?id=50816

Attachment 76294: Updated Patch to handle the first nested paren, not just when
the first nested term is a paren
https://bugs.webkit.org/attachment.cgi?id=76294&action=review

------- Additional Comments from Michael Saboff <msaboff at apple.com>
Thought about this a little more after posting the initial patch.  The initial
patch solves the problem where the first paren in a nested paren is the first
term.  I tried it with patterns where there is some other non-paren term first
in an alternative and it didn't work.  I have modified the fix to work for the
first paren term in an alternative and it works for the original RE as well as
one with a non-paren term inserted before the first nested paren.

Examples:
   The original bug was for the RE: /^\s*((\[[^\]]+\])|(u?)("[^"]+"))\s*/
   and the problem was the (u?) wasn't backtracking to the first (.

   If the RE is modified by (the inserted
X's):/^\s*(X(\[[^\]]+\])|X(u?)("[^"]+"))\s*/
   then the original patch won't work.	The default backtracking for the (u?)
is still
   broken.  The updated fix counts nested parens instead of using the term
number
   and works for both the original and modified REs.