develooper Front page | perl.perl5.porters | Postings from March 2013

Re: Is this a /^*/ bug?

Thread Previous | Thread Next
March 25, 2013 16:37
Re: Is this a /^*/ bug?
Message ID:
Tom Christiansen wrote:
>I think somehow the pointer tracking the position in the string to matched 
>got bumped up inappropriately because of the constant-string-at-the-end

Seems perfectly appropriate, if such optimisation was applied.

>But you are saying that it is ok *not* to match the beginning of the
>string, since 0 or more includes 0, and here we did not match the 
>beginning of the string at all.

Yes.  It matched beginning-of-line zero times, which is within the range
that is compatible with an overall match.

>That's pretty darned ugly, is all I can say.

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.

The actual alternative comes from very old regexp semantics.  In BREs,
"^" isn't a regular (hence quantifiable) regexp node.  Instead, it's
a flag that's only recognised at the very beginning of the regexp, and
has the effect of anchoring the regexp as a whole.  (Similarly "$" at
the end.)  If "^" appears anywhere other than the very beginning then,
as with any other misplaced metachar, it's treated as literal.  Which is
also how "*" is treated when it's at the beginning of the pattern with
nothing to quantify.  So in this system /^*/ matches a literal "*"
at beginning-of-line.


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