2016-11-19 16:45:29 +0000, Stephane Chazelas: > 2016-11-19 16:14:28 +0000, Stephane Chazelas: > [...] > > AFAICT, that optimisation only brings a little optimisation in > > some cases (and reduces performance in others) but also reduces > > functionality and breaks users' expectations. IMO, it's not > > worth it. > [...] > > To be fair, that last part about users' expectations is highly > reduced with your recent changes. Thanks for that and for > re-enabling grep -Pz ^/$ [...]
A few cases left: $ printf 'a\nb\n' | ./grep -P 'a\z' $ printf 'a\nb\n' | pcregrep 'a\z' a Note that it's https://savannah.gnu.org/bugs/?27460 already mentioned whose fix at the time was to stop passing several lines to pcre_exec(). (A regression test could have helped spot this one.) $ printf 'a\nb\n' | ./grep -P 'a[^b]*+$' $ printf 'a\nb\n' | pcregrep 'a[^b]*+$' a *+ is the non-backtracking * (same for other repeating operators). The example is a bit contrieved, but that hopefully illustrates that any extended PCRE operator, current or future could fool that GNU grep optimisation. -- Stephane
