Date: Mon, 08 Feb 2021 18:41:57 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 253350] Grep regression with --after-context (-A) and --max-count (-m) switches Message-ID: <bug-253350-227-WZX8C54ObZ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-253350-227@https.bugs.freebsd.org/bugzilla/> References: <bug-253350-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253350 --- Comment #2 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D3e2d96ac974db823255a6f40b90eeffa6= e38d022 commit 3e2d96ac974db823255a6f40b90eeffa6e38d022 Author: Kyle Evans <kevans@FreeBSD.org> AuthorDate: 2021-02-08 18:31:17 +0000 Commit: Kyle Evans <kevans@FreeBSD.org> CommitDate: 2021-02-08 18:41:22 +0000 grep: fix -A handling in conjunction with -m match limitation The basic issue here is that grep, when given -m 1, would stop all line processing once it hit the match count and exit immediately. The problem with exiting immediately is that -A processing only happens when subsequent lines are processed and do not match. The fix here is relatively easy; when bsdgrep matches a line, it resets the 'tail' of the matching context to the value supplied to -A and dumps anything that's been queued up for -B. After the current line has been printed and tail is reset, we check our mcount and do what's needed. Therefore, at the time that we decide we're doing nothing, we know that 'tail' of the context is correct and we can simply continue on if there's still more to pick up. With this change, we still bail out immediately if there's been no -A flag. If -A was supplied, we signal that we should continue on. However, subsequent lines will not even bothere to try and process the line. We have reached the match count, so even if the next line would match then we must process it if it hadn't. Thus, the loop in procfile() can short-circuit and just process the line as a non-match until procmatches() indicates that it's safe to stop. A test has been added to reflect both that we should be picking up the next line and that the next line should be considered a non-match even if it should have been. PR: 253350 MFC-after: 3 days contrib/netbsd-tests/usr.bin/grep/t_grep.sh | 17 +++++++++++++++++ usr.bin/grep/util.c | 21 ++++++++++++++++++++- 2 files changed, 37 insertions(+), 1 deletion(-) --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-253350-227-WZX8C54ObZ>