BSD grep dumps core

[Dimitry Andric]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20160801/8b1c63bf/attachment.sig>