4 ms·
It seems more developer-friendly to me to, at Regex construction, try to parse as linear, and fallback to a backtracking regex if not. The engine is an implemen
by yunruse 6y ago
It seems more developer-friendly to me to, at Regex construction, try to parse as linear, and fallback to a backtracking regex if not. The engine is an implementation detail that programmers probably care very little about; a linear engine being default but not raising errors would be the best-of-all-worlds scenario.
(It’s a little weird to see the i flag not working with linear regexes, mind. Surely that’s easily implemented when the regex is compiled?)
- eyelidlessness 6y agoThe problem is that it’s hard to know when you’re triggering backtracking or potentially creating a DoS vector. Having these explicit rules helps other tooling. Aside: fun fact, I recently worked on a validation library[1] where input was reasonably expected to come from a web browser. So validating email and URL strings was something I delegated to the HTML spec, rather than finding or developing a validator of my liking. Turns out the URL validation regex in the living HTML spec has pathological backtracking. In my case, I disabled linting on that line because if it’s good enough for Chrome it’s good enough for the users who could make it through that series of client requests. But fair warning! [1]: It’s proprietary so I can’t divulge much, it did much more but that’s the relevant detail I can include.
- coagmano 6y agoI'm guessing that if they can get the non-backtracking algorithm to perform at least as fast, then they'll consider switching the default