Front page | perl.perl5.porters |
Postings from March 2013
Re: Is this a /^*/ bug?
Thread Previous
|
Thread Next
From:
Tom Christiansen
Date:
March 25, 2013 16:22
Subject:
Re: Is this a /^*/ bug?
Message ID:
4802.1364228550@chthon
demerphq <demerphq@gmail.com> wrote on Mon, 25 Mar 2013 17:01:59 BST:
On 25 March 2013 16:55, Tom Christiansen <tchrist@perl.com> wrote:
>> I realize this is nonsense, but I wonder if it is not a bug. Shouldn't the
>> overall pattern still fail, not succeed?
>>
>> % perl -WE 'say "foo.bar" =~ /^.*.bar$/ || "FAIL"'
>> 1
>>
>> % perl -WE 'say "foo.bar" =~ /^*.bar$/ || "FAIL"'
>> ^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE .bar$/ at -e line 1.
>> 1
>>
>> % perl -WE 'say "foo.bar" =~ /(^*).bar$/ || "FAIL"'
>> ^* matches null string many times in regex; marked by <-- HERE in m/(^* <-- HERE ).bar$/ at -e line 1.
>> 1
>>
>> % perl -WE 'say "foo.bar" =~ /^.bar$/ || "FAIL"'
>> FAIL
>>
>> Tested with v5.8.8, v5.14.0, v5.16.0, and v5.17.0-352-g3630f57.
> There might be a case to change this from a warning to a fatal error.
> But its a warning, and as such no, I dont think the pattern should fail:
> $ perl -WE 'say "foo.bar" =~ /^*.bar$/ || "FAIL"' 2>&1 | splain
> ^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE
> .bar$/ at -e line 1 (#1)
> (W regexp) The pattern you've specified would be an infinite loop if the
> regular expression engine didn't specifically check for that. The <-- HERE
> shows in the regular expression about where the problem was discovered.
> See perlre.
> 1
> Consider that ^* means "match at the start of the string 0 or more
> times". So the pattern succeeds because it matches 0 times.
> It warns because it could match at the same spot an infinite number of times.
> All of this is as I expect.
I read is as saying
1 Match the beginning of the string 0 or more times.
2 Match any one non-newline character.
3 Match the constant string "bar"
4 Match the end of the string, with optional newline slop
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
optimization. It fails to account for the "foo" bar, which is why I
believe it is in error.
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.
That's pretty darned ugly, is all I can say.
--tom
Thread Previous
|
Thread Next