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

Re: [perl #133366] *COMMIT bug?

Thread Previous | Thread Next
From:
demerphq
Date:
July 20, 2018 07:01
Subject:
Re: [perl #133366] *COMMIT bug?
Message ID:
7486_1532070079_5B5188BE_7486_53_1_CANgJU+V68yMxdG76GWtNr0Qa4XGkxALp_xX=Tmsc_93FuwizwQ@mail.gmail.com
On Mon, 16 Jul 2018 at 12:39, Abigail <abigail@abigail.be> wrote:
>
> On Fri, Jul 13, 2018 at 12:27:19PM -0400, demerphq wrote:
> > On Fri, 13 Jul 2018, 03:28 , <ph10@hermes.cam.ac.uk> 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.

I think there is a tension between fixing bugs and performance in this case.

Disabling the start point optimizations can have a very serious affect
on performance.

Doing so in any pattern that uses a verb, just to fix an edge case set
of errors that I don't think most people would care about or even
notice, seems wrong.

>
> >
> > 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?

We can, but it isn't clear to me that we should.

Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About