BSD grep dumps core

[Steve Kargl]

On Mon, Aug 01, 2016 at 06:22:16PM +0200, Dimitry Andric wrote:
> On 31 Jul 2016, at 17:37, Steve Kargl <sgk at troutmask.apl.washington.edu> wrote:
> > Script started on Sun Jul 31 08:30:56 2016
> > troutmask:sgk[200] cd gcc/gcc7
> > troutmask:sgk[201] svn status
> > ?       7.diff
> > ?       decl.c.diff
> > ?       gcc/fortran/old
> > ?       gcc/fortran/pr38351.diff
> > ?       gcc/fortran/pr41922.diff
> > ?       gcc/fortran/pr69860.diff
> > ?       trans-decl.c.diff
> > ?       typescript
> > ?       z1.diff
> > troutmask:sgk[202] svn status | grep -v -E ^\?
> > Segmentation fault (core dumped)
> > troutmask:sgk[203] svn status | grep -v -E ^"\?"
> > troutmask:sgk[204] exit
> > exit
> > 
> > Script done on Sun Jul 31 08:31:54 2016
> > 
> > The core dump happens with both tcsh and sh.
> > 
> > The following works as expected
> > 
> > troutmask:sgk[202] svn status | gnugrep -v -E ^\?
> 
> Yes, '^?' is an invalid extended regular expression, but GNU grep does
> not complain about it, and simply discards the '?' character.  Our BSD
> grep dies because it also attempts to discard, but then some later logic
> goes beyond the end of the buffer.
> 
> Please try this fix:
> 
> Index: usr.bin/grep/regex/tre-fastmatch.c
> ===================================================================
> --- usr.bin/grep/regex/tre-fastmatch.c  (revision 303551)
> +++ usr.bin/grep/regex/tre-fastmatch.c  (working copy)
> @@ -621,7 +621,7 @@ tre_compile_fast(fastmatch_t *fg, const tre_char_t
>           case TRE_CHAR('+'):
>           case TRE_CHAR('?'):
>             if ((cflags & REG_EXTENDED) && (i == 0))
> -             continue;
> +             goto badpat;
>             else if ((cflags & REG_EXTENDED) ^ !escaped)
>               STORE_CHAR;
>             else
> 
> After this, bsdgrep errors out with:
> 
> % bsdgrep -E '^?'
> bsdgrep: Invalid preceding regular expression
> 
> which is much saner IMHO.
> 

Dimitry,

Thanks for the quick patch.  Yes, the patch works as advertised.
I agree that an error message is preferredi/saner than a segfault.

-- 
Steve