It does not make sense to me, best solution is to have an implementation like re2 that does not have those problems.

Adding a timeout is a bit strange, first because you don't know in advance how long it's going to take for large search. The timeout is a failsafe against something that should be fixed in the first place.

You can use re2 in Ruby if you like - it's just not the default. https://github.com/mudge/re2

    best solution is to have an implementation like re2 that does not have those problems.

By design RE2 isn't fully compatible with Onigmo. As another poster mentioned, a hybrid "use RE2 when possible; fall back to Onigmo otherwise" approach was considered and rejected for well-explained reasons https://bugs.ruby-lang.org/issues/18653

Maybe in addition to `Regexp.timeout = 1.0` there could also be a `Regexp.parser = :re2` option with `:onigmo` being the default.

I think a limit on stack/recursion/backtracking depth would be tad a bit more elegant than a timeout and would keep your code behaviour the same between different machines.

It'd be harder to control perceived performance of user facing applications though. If I can set the timeout, I can guarantee that something happens within X seconds, instead of within X iterations which could have different performance machine to machine.

is this not the halting problem? You can guarantee a certain depth isnt reached but you cant guarantee a recursion will unwind or anything like that

No, because we’re not trying to find out if the computation will ever halt with unbounded time. It just determines if it will halt after a certain number of steps, which you can always determine by executing that number of steps and bailing out.

It's not the halting problem; it's bounding computational depth

Their suggestion is essentially making stack overflow a feature in regex, & then allowing that stack depth to be tuned

Wooosh

thats the problem with all these syntax sugar features in languages. you literally can't change them without blowing up your entire ecosystem.

How would this problem be different if Ruby did not have syntax support for regexes and instead offered a regex module in the standard library?

If it isn’t syntax then it is a function/method call. By being a method call, one can define default options, allowing overridability.

They could easily add another regex flag to indicate a "safe" regex. That really isn't the problem here. The problem is that adding a safe regex engine doesn't retroactively fix the thousands and thousands of regexes in gems which can't be unilaterally forced over to the new engine.

actually that is the problem. no they can't 'easily' add a new flag (or they would have). it doesn't fix the problem of being broken by default and any fundamental change in behavior will lead to problems as well.

the point is the language is broken fundamentally and because its syntax sugar there isn't anything you can do realistically. a function call can be replaced, deprecated, and then removed and all of that can be automated and be non-disruptive over a few releases.

> It does not make sense to me

What are your credentials for being you?

The grand-parent post exhibits feigned confusion and using opinions as arguments. It also proposes an _optimal_ solution that will most likely not get implemented in place of pragmatic solution. We see this kind of argumentation when discussing crypto libraries.

The OP is not _confused_, they just don't like the solution.

It makes zero sense, if I'm completely honest. Why stop to regexps? What about every other long-running function? This is better handled on a layer above, in a general fashion - imagine a server running some queries and being able to kill/discard/interrupt them in case they seem stuck.

If you don’t stop long processes on a server, you expose yourself to denial of service attacks. It’s good practice to have a maximum duration for database queries as well.

Of course you should limit the query duration - just not on some arbitrary function-level like done here. To me this sounds like PHP-level incompetence on API design.