develooper Front page | perl.perl5.porters | Postings from September 1999

Re: Regular Expression Bug

Ilya Zakharevich
September 7, 1999 01:02
Re: Regular Expression Bug
Message ID:
On Mon, Sep 06, 1999 at 08:56:18PM -0600, Ed Peschko wrote:
> > Some other idea of Ed: C<*> could notice that it is
> > inside (?>), and could do no backtracking at all.
> Well, that's what I sort of assumed ?> was when I saw it.

Oups: I meant

  "will not store backtracking information since it is not needed anyway"

And I remembered that this idea is not new: probably any "trailing"
"+*{}" can be convereted to CURLYM (the version which is not storing
backtracking info - used in those situations when backtracking info
can be deduced "on the fly").

[Well for "absolutely" trailing stuff the situation is not *that*
 simple, since the REx may be used from (?p{}), and then the trailing
 "+*{}" *will* backtrack.]

> Just to dwell
> on it a bit, a 'no backtracking' operator would be very useful,
> especially in conjunction with \G. I've been playing around with the qr{
> ... (?p { ... } }; syntax to match things like #ifdef..#endif. Its cool,
> but *very* easy to end up inside 'endless' regular expressions. Take
> something like:
> $qr = qr{
>             {
>                 (?:
>                     (?> [^{}]*) |
>                     (?p{ $qr })
>                 )*
>             }
>         }x;
> and the alternation of (?: (?> *) ...| (?p { .. }))* does not work very
> well when you lose a trailing ')' off of a 16K block. With a \G in place
> at the beginning of a regex - or a literal string plus other occurrences
> of (?>), you should be able to scan the string once, see that it doesn't
> match the trailing ')' and go on.

I do not follow this \G stuff.  Where do you want to put it?

> Example:
> $trycatchre =
> "(?>try\\s*$curlyblock\\s*catch\\s*$parenblock\\s*$curlyblock)";

Please do not use qq"" to deal with RExen.

Ilya Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About