develooper Front page | perl.perl5.porters | Postings from July 2018

Re: [perl #133366] *COMMIT bug?

Thread Previous | Thread Next
July 16, 2018 10:39
Re: [perl #133366] *COMMIT bug?
Message ID:
On Fri, Jul 13, 2018 at 12:27:19PM -0400, demerphq wrote:
> On Fri, 13 Jul 2018, 03:28 , <> wrote:
> > On Thu, 12 Jul 2018, Abigail via RT wrote:
> >
> > > What seems to happen is that the optimizer is too eager. It finds the 'D'
> > > in both the pattern and the string, and determines that if the pattern
> > > matches, it should start matching 2 characters before the 'D'. This is
> > > a valid strategy if the (*COMMIT) is not present, but not in the presence
> > > of it.
> >
> > Aha! Optimizing does that kind of thing - PCRE has/had similar issues.
> > One of the PCRE users has been checking out all kinds of stuff and
> > comparing with Perl. There seem to be some odd anomalies in the handling
> > of captures in negative assertions and in the handling of (*VERB)s in
> > subroutine calls in Perl. Would it be helpful if I reported these as
> > independent issues
> >
> Definitely. Although I have to admit we might not "simply" fix this but
> instead add a modifier to disable the start position optimizations and
> advise users to consider using the modifier in such cases where it matters.

That just feels wrong to me. That reads as "we know there's a bug, we
have a fix, but you need to jump through some extra hoops to enable
the fix". Not to mention that most people will not know when they
should enable this.

> Fwiw there is already an internal flag which disables such optimisations.
> For instance add a (??{""}) to the pattern and you should get the expected
> results.

Can't we make it so that the mere presence of a "(*COMMIT)" disables
this optimization?


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