GNU bug report logs - #22655
grep-2.21 (and git master): --null-data and ranges work in an odd way (-P works fine)

Previous Next

Full log

Message #109 received at 22655 <at> debbugs.gnu.org (full text, mbox):

From: Stephane Chazelas <stephane.chazelas <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 22655 <at> debbugs.gnu.org
Subject: Re: bug#22655: grep -Pz '^' now fails!
Date: Sat, 19 Nov 2016 21:52:35 +0000

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.