Regex Decision Procedures in Extended RE#
Ian Erik Varatalu, Margus Veanes, Ekaterina Zhuchko, Juhan P. Ernits
Abstract
We develop decision procedures for extended regular expressions in the new ERE# framework that uses span semantics, utilizing the power of symbolic derivatives. We prove a normal form theorem in Lean for ERE# that is closed under all Boolean operations and provides the basis for the given decision procedures. The tool is evaluated on existing SMT benchmarks for regexes that shows it to be the fastest solver to date -often orders of magnitude faster than state-of-the-art -albeit specialized for the single-variable fragment of string theory.
a regex ๐ = .*a?๐ for a is ๐ |a?๐-1 that can be simplified to ๐ because ๐ subsumes a?๐-1, where a? abbreviates a|๐. Omitting such rewrites can quickly lead to a state space explosion up to size 2 ๐ -observe that ๐ = ๐ (2 | ๐ | ) here! For DFA generation, such subsumption checking must be fast in practice.
Dealing with differences between PCRE and POSIX semantics for a regex is a common problem. 3 In PCRE, also known as backtracking or leftmost-eager semantics, the union operator | is noncommutative where in a regex ๐ 1 |๐ 2 , a match for ๐ 2 is only sought when ๐ 1 fails to match. Note that this difference is relevant for span semantics that has recently been formalized in Lean [50], but irrelevant for language semantics (IsMatch) that is identical under both PCRE and POSIX. A technique to decide if a union ๐ 1 |๐ 2 in PCRE has the same span semantics under POSIX, where union is commutative, is to decide match equivalence between ๐ 1 |๐ 2 and
If the span semantics of a regex differs between PCRE and POSIX then the regex may contain unreachable cases under PCRE. E.g., the BurntSushi/rebar benchmarking tool [24] -widely used for industrial PCRE matchers -uses a dictionary benchmark containing unions such as may|mayo. The regex may|mayo will never match "mayo" for any input under PCRE semantics and has the exact same behavior as the regex may. Most industrial regex matchers use PCRE semantics, resulting in different behavior to what is intuitively assumed, as | is not union of languages in PCRE. It is a common programming error to define a regex with unintended behavior this way. For example, by using the above technique, may|mayo& (may_) effectively deletes the alternative mayo from may|mayo while mayo|may would remain intact because may& (mayo_) โก may.
The logic ERE#, that is introduced in Section 4, is a novel contribution and fundamental for many decision problems. In particular, it lifts RE# to the status of an Effective Boolean Algebra over spans. RE# is closed only under intersection and each regex admits a linear translation to a core regex of the form (?<=๐ 1 )๐ 2 (?=๐ 3 ) where no ๐ ๐ contains lookarounds. The span semantics
where ๐ข 2 is the main match with ๐ข 1 and ๐ข 3 as the surrounding context. For many decision problems, like subsumption, it became necessary to support regexes like (?<=๐ 1 )๐ 2 (?=๐ 3 )& ((?<=๐ โฒ 1 )๐ โฒ 2 (?=๐ โฒ 3 )) that fall outside the fragment for matching in RE#.
Currently, ERE# semantics is not directly expressible in SMT-LIB as it would require support for lookarounds and span semantics. Section 7 proposes an SMT-LIB format for extending RegLan with lookarounds and span semantics.
Contributions. We introduce an extension ERE# of the RE# class that is Boolean closed and formalize a normal form theorem (Theorem 2) for it in Lean allowing us to develop decision procedures for ERE#, including emptiness, subsumption, and equivalence, that are of primary interest in the ERE# framework, as discussed above. It is also possible to use ERE# for pre-processing in SMT solvers. One can invoke ERE# from the simplifier in Z3 [39], to pre-process
Ask about this paper
Your agent reads all of it.
Lune indexed this paper to the last equation, along with the top-tier papers that cite it. Ask a question and the answer quotes them.
Your agent calls
Luneget_paper_fulltext
Free to start. No credit card required.
Terminal
Install the CLIlune papers fulltext 66e04d2c-9b98-4219-b8d0-25a7052f2df4Builds on16
- Solving string constraints with Regex-dependent functions through transducers with priorities and variablesTaolue Chen, Alejandro Flores-Lamas, Matthew Hague, Zhilei Han et al.POPL 2022 ยท 39 citations
- Symbolic Boolean derivatives for efficiently solving extended regular expression constraintsCaleb Stanford, Margus Veanes, Nikolaj S. BjรธrnerPLDI 2021 ยท 38 citations
- An SMT Solver for Regular Expressions and Linear Arithmetic over String LengthMurphy Berzish, Mitja Kulczynski, Federico Mora, Florin Manea et al.CAV 2021 ยท 37 citations
- Z3str4: A Multi-armed String SolverFederico Mora, Murphy Berzish, Mitja Kulczynski, Dirk Nowotka et al.FM 2021 ยท 30 citations
- Derivative Based Nonbacktracking Real-World Regex Matching with Backtracking SemanticsDan Moseley, Mario Nishio, Jose Perez Rodriguez, Olli Saarikivi et al.PLDI 2023 ยท 21 citations
Related papers
- RE#: High Performance Derivative-Based Regex Matching with Intersection, Complement, and Restricted LookaroundsIan Erik Varatalu, Margus Veanes, Juhan P. ErnitsPOPL 2025 ยท 9 citations
- Even Faster Conflicts and Lazier Reductions for String SolversAndres Nรถtzli, Andrew Reynolds, Haniel Barbosa, Clark W. Barrett et al.CAV 2022 ยท 13 citations
- Repairing Regular Expressions for ExtractionNariyoshi Chida, Tachio TerauchiPLDI 2023 ยท 9 citations
- Exploiting Structure in Regular Expression QueriesLing Zhang, Shaleen Deep, Avrilia Floratou, Anja Gruenheid et al.SIGMOD 2023 ยท 3 citations
- EREQ: Regular Expressions with Quantifiers and Incremental Quantifier EliminationEkaterina Zhuchko, Ian Erik Varatalu, Margus Veanes, Nikolaj S. BjรธrnerPLDI 2026
