Re: [pcre-dev] [Bug 547] full regular expression support ins…

Top Page

Reply to this message
Author: Philip Hazel
Date:  
To: Ze'ev Atlas
CC: pcre-dev@exim.org, admin@bugs.exim.org
Subject: Re: [pcre-dev] [Bug 547] full regular expression support inside lookbehind
In theory it might be possible, but the emulation has no limit on how far
back it looks, which could lead to a lot of recursion and hence be very
expensive in resources. Experiments with Perl's new experimental feature
show that it only supports lookbehinds that have a minimum and maximum
length, e.g. (?<=a{4,5}) NOT those of indefinite length such as (?<=a+),
with a maximum length of 255. I guess that it tries to match at each
possible lookbehind length, but have not confirmed that. I continue to
think about this from time to time.
Regards,
Philip


On Wed, 27 Jan 2021 at 03:12, Ze'ev Atlas via Pcre-dev <pcre-dev@???>
wrote:

> Many on the internet suggest emulating variable length lookbehind by using
> lookaheads (see for example Dr. Regex: Variable-Length Lookbehinds:
> actually possible in Perl/PCRE!). Is it possible to implement such a
> solution by doing the conversion internally?
>
> Ze'ev Atlas
>
>     On Tuesday, January 19, 2021, 12:01:32 PM EST, <admin@???>
> wrote:

>
> https://bugs.exim.org/show_bug.cgi?id=547
>
> --- Comment #5 from Philip Hazel <Philip.Hazel@???> ---
> Fixed-length lookbehind is (relatively) simple: you move back a fixed
> number of
> characters, then apply the normal matching algorithms. That's what PCRE and
> Perl (until recently) do. I see that Perl 5.3 has some experimental
> support for
> variable length. The documentation says this: "Prior to Perl 5.30, it
> worked
> only for fixed-width lookbehind, but starting in that release, it can
> handle
> variable lengths from 1 to 255." It goes on to say that this is
> experimental
> and may be removed if insurmountable problems arise. I have no idea how it
> is
> implemented, but the 255 limit suggests it is perhaps trying a minimum
> length
> and then continuing to move backwards (up to the limit). If something
> similar
> were implemented in PCRE I'm sure the performance would be lousy.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> --
> ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
>
> --
> ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
>