pepita, 10 months ago

deleted_by_author

timbray, 10 months ago

@pepita My impression was that in practical terms those ranges are safe to use for the foreseeable future. \d and \s are actively pernicious.

aegilops, 10 months ago

@timbray Aside from the engines you mentioned, is it worth also referencing how this affects grep, grep -E and POSIX regex? Grep is still a mainstay!

Java and C# are also major languages that are sometimes used in protocol processing relevant to the IETF.

Can Java’s built-in regex conform easily?

https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html

C# says it is Perl 5 compatible, so I’d expect so.

timbray, 10 months ago

@aegilops My impression is that the I-Regexp subset should Just Work for grep & friends. I believe Java is a PCRE subset so that should be fine too.

aegilops, 10 months ago

@timbray I wonder how close the match is to #Hyperscan. That’s Intel’s high-perf regex engine, which disallows backreferences, lookarounds and capture groups, much like I-Regex.

https://www.intel.com/content/www/us/en/developer/articles/technical/introduction-to-hyperscan.html

If you want more fodder for considering which regexes would work in your spec, they have a corpus of thousands available.

Hyperscan does allow ., \s, \d and so on, so you’re even stricter!

#regex

nogweii, 10 months ago

@timbray very cool! Love to see it. I didn't see any discussion on the greediness of the quantifiers. I guess the interoperable assumption is very greedy by default.

underlap, 10 months ago

@timbray Congratulations to you and Carsten! Let's see who uses this, apart from JSONPath...

josephholsten, 10 months ago

@timbray That’s a lovely ABNF! I don’t often get to see many more complex than RFC-2822 headers.

spacecowboy, 10 months ago

@timbray great initiative!

robpike, 10 months ago

@timbray No backreferences!! Yay. I hope all implementations that may arise later appreciate that it can be done in O(n) time always. Theory is your friend. Nice.

timbray, 10 months ago

@robpike Realistically, probably only of use for boolean does-it-match-or-not, but that's an interestingly big part of the problem space.

robpike, 10 months ago (edited 10 months ago)

@timbray I still think this is great. Thanks or congratulations or whatever is appropriate.

modenaboy, 10 months ago

@robpike @timbray I second the motion. This sounds like a very valuable approach, focusing on a common and core use case with an eye towards reliability and interoperability. Thanks for all the work that went into this!

rlb, 10 months ago

@timbray @robpike spelling "does it match or not" is easier outside the regexp language anyway, IMO. People try to cram too many things into the regexp matching and we end up with attempts to range-limit IPv4 octets textually.