Related articles |
---|
Interesting paper on regex NFA matching johnl@taugh.com (John R Levine) (2024-01-25) |
Re: Interesting paper on regex NFA matching cross@spitfire.i.gajendra.net (2024-01-26) |
Re: Interesting paper on regex NFA matching 433-929-6894@kylheku.com (Kaz Kylheku) (2024-01-26) |
Re: Interesting paper on regex NFA matching christopher.f.clark@compiler-resources.com (Christopher F Clark) (2024-01-27) |
Re: Interesting paper on regex NFA matching 433-929-6894@kylheku.com (Kaz Kylheku) (2024-01-27) |
Re: Interesting paper on regex NFA matching christopher.f.clark@compiler-resources.com (Christopher F Clark) (2024-01-29) |
Re: Interesting paper on regex NFA matching 433-929-6894@kylheku.com (Kaz Kylheku) (2024-01-29) |
[2 later articles] |
From: | John R Levine <johnl@taugh.com> |
Newsgroups: | comp.compilers |
Date: | Thu, 25 Jan 2024 22:10:56 -0500 |
Organization: | Compilers Central |
Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="55512"; mail-complaints-to="abuse@iecc.com" |
Keywords: | lex, NFA, performance |
Posted-Date: | 25 Jan 2024 22:12:43 EST |
The easiest way to implement regular expressions is to turn them into
NFAs, but that has well known problems that if you feed hostile input
to the NFAs, they can take exponential time and it's a way to DDoS the
server. If you translate the NFA to a DFA it runs in linear time, but
if the regex is ambiguous, as many are, the DFA may match something
different from the NFA.
This paper on the Arxiv preprint server proposes some rather complex
tweaks to NFA regex matching to fix many performance issues while giving
the same answers as before.
https://arxiv.org/abs/2401.12639
Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
Return to the
comp.compilers page.
Search the
comp.compilers archives again.