You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, the parser uses a seriously large amount of stack for patterns with 255 nested parentheses. The unit tests running in CI need to have the stack limit increased on several platforms to cope with this, for example on platforms where there's 1MiB of stack (which should Enough for Anybody™).
It would be perfectly feasible, technically, to have one giant loop with explicit stack management that spills the parser state to the heap when encountering very deeply-nested parens.
With my security hat on, it would be really nice if PCRE2 had roughly ~fixed stack usage, to mitigate the risk of a customer's application crashing when a user supplies a big regex that causes megabytes of stack to be consumed.
The text was updated successfully, but these errors were encountered:
At the moment, the parser uses a seriously large amount of stack for patterns with 255 nested parentheses. The unit tests running in CI need to have the stack limit increased on several platforms to cope with this, for example on platforms where there's 1MiB of stack (which should Enough for Anybody™).
It would be perfectly feasible, technically, to have one giant loop with explicit stack management that spills the parser state to the heap when encountering very deeply-nested parens.
With my security hat on, it would be really nice if PCRE2 had roughly ~fixed stack usage, to mitigate the risk of a customer's application crashing when a user supplies a big regex that causes megabytes of stack to be consumed.
The text was updated successfully, but these errors were encountered: