Change Details

Currently at 32, MAX_LINE_MATCHES is not necessarily reasonable as a cap on the number of matches we can produce for a given line. In fact, there probably is no such thing as a reasonable cap. If in one invocation we've matched more than MAX_LINE_MATCHES, keep processing and matching from the last match we found until we've found all matches. While we're here, go ahead and make sure we're doing file/line metadata properly on a per-match basis if we need to. I found while testing the other behavior against GNU grep that we did not do this properly, and neither does gnugrep in base. The primary issue, excessive matching, was reported in conjunction with -w breakage in PR 218811, this patch fixing up the remaining issue reported. PR: 218811

Currently at 32, MAX_LINE_MATCHES is not necessarily reasonable as a cap on the number of matches we can produce for a given line. In fact, there probably is no such thing as a reasonable cap. If in one invocation we've matched more than MAX_LINE_MATCHES, keep processing and matching from the last match we found until we've found all matches. For the regression test, we produce a number of matches that will likely be larger than we'll ever raise MAX_LINE_MATCHES to, 4096, and make sure we actually get 4096 lines of output with the -o flag so that we know we're not truncating it for certain numbers of matches close to or at MAX_LINE_MATCHES. We'll also make sure that every distinct line is getting its own line number to detect line metadata not being printed as appropriate along the way. This test does not currently pass with bsdgrep or gnugrep in base. The former will be fixed in another patch correcting metadata printing for all combinations of -o/--color. The primary issue, excessive matching, was reported in conjunction with -w breakage in PR 218811, this patch fixing up the remaining issue reported. PR: 218811

Currently at 32, MAX_LINE_MATCHES is not necessarily reasonable as a cap on the number of matches we can produce for a given line. In fact, there probably is no such thing as a reasonable cap. If in one invocation we've matched more than MAX_LINE_MATCHES, keep processing and matching from the last match we found until we've found all matches. While we're hereFor the regression test, we produce a number of matches that will likely be larger than we'll ever raise MAX_LINE_MATCHES to, go ahead and make sure we're doing file/line metadata properly on a per-match basis if we need to4096, and make sure we actually get 4096 lines of output with the -o flag so that we know we're not truncating it for certain numbers of matches close to or at MAX_LINE_MATCHES. I found while testing the other behavior against GNU grep that we did not do this properly,We'll also make sure that every distinct line is getting its own line number to detect line metadata not being printed as appropriate along the way. This test does not currently pass with bsdgrep or gnugrep in base. and neiThe former will be fixed in another does gnugrep in basepatch correcting metadata printing for all combinations of -o/--color. The primary issue, excessive matching, was reported in conjunction with -w breakage in PR 218811, this patch fixing up the remaining issue reported. PR: 218811