608
|
1 |
% Chapter Template
|
|
2 |
|
|
3 |
\chapter{Related Work} % Main chapter title
|
|
4 |
|
|
5 |
\label{RelatedWork}
|
|
6 |
|
|
7 |
In this chapter, we introduce
|
|
8 |
the work relevant to this thesis.
|
|
9 |
|
|
10 |
|
|
11 |
\section{Work on Back-References}
|
|
12 |
We introduced back-references
|
|
13 |
in chapter \ref{Introduction}.
|
|
14 |
This is a quite deep problem,
|
|
15 |
with theoretical work on them being
|
|
16 |
fairly recent.
|
|
17 |
|
|
18 |
Campaneu gave
|
|
19 |
|
|
20 |
|
|
21 |
See \cite{AHO1990255} for a survey
|
|
22 |
of these works and comparison between different
|
|
23 |
flavours (e.g. whether references can be circular,
|
|
24 |
can labels be repeated etc.) of back-references syntax.
|
|
25 |
|
609
|
26 |
|
|
27 |
\subsection{Matchers and Lexers with Mechanised Proofs}
|
|
28 |
We are aware
|
|
29 |
of a mechanised correctness proof of Brzozowski's derivative-based matcher in HOL4 by
|
|
30 |
Owens and Slind~\parencite{Owens2008}. Another one in Isabelle/HOL is part
|
|
31 |
of the work by Krauss and Nipkow \parencite{Krauss2011}. And another one
|
|
32 |
in Coq is given by Coquand and Siles \parencite{Coquand2012}.
|
|
33 |
Also Ribeiro and Du Bois give one in Agda \parencite{RibeiroAgda2017}.
|
|
34 |
|
|
35 |
\subsection{Static Analysis of Evil Regex Patterns}
|
|
36 |
When a regular expression does not behave as intended,
|
|
37 |
people usually try to rewrite the regex to some equivalent form
|
|
38 |
or they try to avoid the possibly problematic patterns completely,
|
|
39 |
for which many false positives exist\parencite{Davis18}.
|
|
40 |
Animated tools to "debug" regular expressions such as
|
|
41 |
\parencite{regexploit2021} \parencite{regex101} are also popular.
|
|
42 |
We are also aware of static analysis work on regular expressions that
|
|
43 |
aims to detect potentially expoential regex patterns. Rathnayake and Thielecke
|
|
44 |
\parencite{Rathnayake2014StaticAF} proposed an algorithm
|
|
45 |
that detects regular expressions triggering exponential
|
|
46 |
behavious on backtracking matchers.
|
|
47 |
Weideman \parencite{Weideman2017Static} came up with
|
|
48 |
non-linear polynomial worst-time estimates
|
|
49 |
for regexes, attack string that exploit the worst-time
|
|
50 |
scenario, and "attack automata" that generates
|
|
51 |
attack strings.
|
622
|
52 |
|
|
53 |
|
|
54 |
|
|
55 |
|
|
56 |
|
|
57 |
|
|
58 |
Thanks to our theorem-prover-friendly approach,
|
|
59 |
we believe that
|
|
60 |
this finiteness bound can be improved to a bound
|
|
61 |
linear to input and
|
|
62 |
cubic to the regular expression size using a technique by
|
|
63 |
Antimirov\cite{Antimirov95}.
|
|
64 |
Once formalised, this would be a guarantee for the absence of all super-linear behavious.
|
|
65 |
We are working out the
|
|
66 |
details.
|
|
67 |
|
|
68 |
|
|
69 |
To our best knowledge, no lexing libraries using Brzozowski derivatives
|
|
70 |
have similar complexity-related bounds,
|
|
71 |
and claims about running time are usually speculative and backed by empirical
|
|
72 |
evidence on a few test cases.
|
|
73 |
If a matching or lexing algorithm
|
|
74 |
does not come with certain basic complexity related
|
|
75 |
guarantees (for examaple the internal data structure size
|
|
76 |
does not grow indefinitely),
|
|
77 |
then they cannot claim with confidence having solved the problem
|
|
78 |
of catastrophic backtracking.
|