bug#15758: grep 2.15 calls abort() on larger searches with -P

[Jim Meyering]

On Mon, Nov 4, 2013 at 11:38 AM, Dave Reisner <address@hidden> wrote:
> On Sat, Nov 02, 2013 at 04:05:52PM -0700, Jim Meyering wrote:
>> On Thu, Oct 31, 2013 at 8:26 AM, Jim Meyering <address@hidden> wrote:
>> ...
>> > With this and the nit about --version output being wrong, I now have
>> > two reasons to make a new release.
>>
>> Thanks again for the report, Dave.
>> Here's the fix I expect to push:
>
> Thanks Jim.
>
> Apologies for not responding to this sooner. I tested your patch and can
> confirm that the behavior is better, but the new behavior still seems
> like a regression. Take, for example, the simple instance of grep'ing
> grep's own git repo.
>
> # with grep 2.14
> $ grep -rPw GNULIB
> gnulib/m4/bison.m4:dnl Declaring YACC & YFLAGS precious will not be necessary 
> after GNULIB
> gnulib/lib/glob.c:   HAVE_STRUCT_DIRENT_D_TYPE plays the same role in GNULIB. 
>  */
> gnulib/lib/netdb.in.h:   GNULIB getaddrinfo() replacement, so are not yet 
> needed.
> gnulib/lib/argp.h:/* GNULIB makes sure both program_invocation_name and
>
> # with grep built from HEAD
> $ ./src/grep -rPw GNULIB
> ./src/grep: invalid UTF-8 byte sequence in input
>
> I would expect that the invalid UTF-8 wouldn't stop grep cold, but
> continue on, ignoring the non-matching data, just as grep without the -P
> flag does.

Hi Dave,

I agree, and so does pcregrep.  There are a few other problems with
grep's PCRE driver code: for example, a problem (no matter how serious)
in one file should not cause the entire grep run to exit; grep should
continue processing remaining files. And when grep reports the problem,
it should include at least the file name in the diagnostic.

I will fix those before the upcoming snapshot.

Thanks,
Jim