*Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.*
I would tend to agree with this statement. Regular expressions are much abused and over-used in situations where simpler parsing techniques would be more appropriate. Beyond a certain length regular expressions are hard to read, and easy to get wrong. But when you do need to use a regular expression, then it the implementation in the standard library is usually a good choice. Its most important feature is O(n) runtime - runtime proportional to the input length, irrespective of the complexity of the regular expression. This prevents denial of service attacks based on sending regular expression which cause catastrophic backtracking and exponential runtime. The standard library omits some of the bells and whistles provided by PCRE and other libraries - but often for the good reason that these require backtracking, so are impossible to implement while guaranteeing reasonable runtimes. So I would certainly consider using the standard library version, and rewriting your regular expressions to remove the use of features not supported in the standard library. On Friday, 2 April 2021 at 01:43:00 UTC+1 dlc...@gmail.com wrote: > You can try my regexp2 engine that's based on the .NET engine: > https://github.com/dlclark/regexp2 > > It supports atomic groups, has no dependencies, and doesn't need cgo. > Unfortunately it doesn't support Possessive Quantifier syntax, but > supposedly that may be serving as syntactic sugar for atomic groups and > look-ahead assertions (which it does support). > > Thanks, > Doug > > On Thursday, April 1, 2021 at 2:54:35 PM UTC-5 bobj...@gmail.com wrote: > >> I have a use of regular expressions where I need the "atomic" matching >> features that I can get for several other languages, such as atomic >> matching groups and "possessive" quantifiers. I'm willing to forego the >> blazing performance of Go's standard library dfa matcher for this >> particular case. I cannot write an equivalent regexp for Go's "regexp", and >> the additional code I would have to write for equivalent functionality is >> prohibitive. >> >> I did find such an implementation in the ether, importable as " >> github.com/h2so5/goback/regexp", It kind of works, but fails for my use >> case. >> >> Is there any reason to believe that downloaded modules such as this are >> well-tested and reliable? >> >> To pursue this problem,, I wrote small programs that perform the same >> operation in isolation in some other languages that have regular expression >> implementations the have the features I want, in particular >> Java, whose java.util.regex module provides the desired features >> Python, which has a module "regex" downloadable from the PyPI (Python >> program index) that replaces the standard "re" module but has my desired >> features >> Also Go, using the downloaded module I mentioned >> >> Only the Go version fails. Of course, it's the fault of the downloaded >> library, not Go itself :) >> >> Anyone know of any other Go nfa implementations with the aforementioned >> features? >> >> As much as I appreciate the advantages Go's dfa "regexp" module, there >> are times when a more full-featured nfa implementation is useful. (And, a >> well-written regexp for nfa can be pretty fast if the aforementioned >> features are used to prevent excessive backtracking.) >> >> If anyone is interested in looking into the failure I experienced, I'd be >> happy to send the little programs I wrote to investigate this. >> >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d08ed242-fdef-4954-ab66-c1a7c479b9a6n%40googlegroups.com.
