Front page | perl.perl5.porters |
Postings from March 2013
Re: Is this a /^*/ bug?
Thread Previous
|
Thread Next
From:
hv
Date:
March 26, 2013 09:26
Subject:
Re: Is this a /^*/ bug?
Message ID:
201303260800.r2Q809u27606@crypt.org
"A. Pagaltzis" <pagaltzis@gmx.de> wrote:
:* Zefram <zefram@fysh.org> [2013-03-25 17:40]:
:> What's the alternative? If the "*" is interpreted as a quantifier
:> (which is how you read it), the only thing it can be quantifying is
:> /^/. The observed behaviour is the perfectly regular result of
:> applying the quantifier to the anchor. A match failure would require
:> some irregular rule, which would be uglier.
:
:Should zero-width assertions in general be quantifiable at all?
I believe so. The canonical example is optional lookahead with capture
/(?=x(y)z)?/ - the side-effect of capture makes it a not necessarily
useless thing to do.
:What would be the fallout of making that a compile-time error?
A bunch of stuff would fall over at runtime; in a small number of cases
that would highlight a bug that might not otherwise have been found, or
found as quickly; in most cases it will already have been doing what
was wanted, and people will either change the pattern to something
equivalent-but-legal (if a fixed pattern), or put in extra (probably buggy)
logic to detect and change to equivalent-but-legal for a constructed pattern.
I say "probably buggy", because detecting this in the general case is quite
hard: I think you can't do it with anything short of a full regexp parser.
:If too bad, what of optimising them away with a specially worded warning?
That's exactly what we do now. The specially worded warning is "matches null
string many times in regex", and you can see the optimization under debug:
% perl -Mre=debug -wle '"foo" =~ /^+f/' 2>&1 | grep 'while'
whilem: matched 0 out of 1..32767
whilem: matched 1 out of 1..32767
whilem: empty match detected, trying continuation...
%
Without optimization, it would match 32767 of them before continuing.
Hugo
Thread Previous
|
Thread Next