https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78276
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2026-01-30
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Tim Shen from comment #1)
> We could have thrown error_complexity here, but I didn't implement that yet.
I'm not sure that we want to do that. The original example in comment 0 takes
4s on my machine at -O0, but who cares about performance at -O0? Don't do that.
With optimization enabled, it's half a second for GCC 15. That seems fast
enough for a silly regex. If we added code to throw an exception because it is
too complex, then that's just imposing an arbitrary limit. Some users might be
willing to wait half a second for the result of their silly regex.
on regex101.com PCRE, PCRE2, and Python do fail, reporting:
Catastrophic backtracking has been detected and the execution of your
expression has been halted. To find out more and what this is, please read the
following article: Runaway Regular Expressions
<https://www.regular-expressions.info/catastrophic.html>
ECMAScript, Go, Java, .NET and Rust all match successfully.
