# Regular expressions are hard

Writing a high-quality implementation of POSIX Extended Regular Expressions does not seem easy.
Ideally, the following features would be offered at the same time:

* Strict standards compliance (see https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap09.html and https://pubs.opengroup.org/onlinepubs/9799919799/functions/regexec.html).
* Predictable performance (polynomial in the length of the inputs, and linear in the length of the matched string).
* Limited resource usage (memory, CPU time (also related to the previous point)).
* Absence of vendor-specific syntax extensions (for portability).

In practice, most implementations fall short of these goals, due to a variety of issues:

* Unclear wording in the standards, leading to diverging outcomes between implementations.
* Exponential matching time due to backtracking implementation (sometimes even mandated by non-standard syntax extensions).
* Excessive consumption of stack memory.
* Spurious matching failures (either indication of a non-match, or an error).
* Incorrect capturing behaviour of parenthesised subexpressions.

Here we test a small sample of regular expressions that are known to be hard to match properly against a couple of popular regex engines.

## Run it

Build using Lix:

    nix-build -A default # or libcxx, or musl

List all available engines:

    result/bin/driver list

Check the specified engines (tries all if none is specified, not recommended on libstdc++ because `std` may crash):

    result/bin/driver check [engine]…

Print the match results of the specified engines (tries all if none is specified, not recommended on libstdc++ because `std` may crash):

    result/bin/driver results [engine]…

## List of supported engines

* Boost.Regex (`boost`)
* C standard library (`c`)
* Oniguruma (`oniguruma`, does not claim POSIX compliance)
* PCRE2 (`pcre`, does not claim POSIX compliance)
* RE2 (`re2`, does not claim POSIX compliance)
* C++ standard library (`std`)
* TRE (`tre`)