Re: [PATCH 2/5] grep: stop modifying buffer in show_line()

On Tue, Sep 21, 2021 at 12:22:45AM -0400, Taylor Blau wrote:

On Mon, Sep 20, 2021 at 11:48:09PM -0400, Jeff King wrote:

quoted

When showing lines via grep (or looking for funcnames), we call
show_line() on a multi-line buffer. It finds the end of line and marks
it with a NUL. However, we don't need to do so, as the resulting line is
only used along with its "eol" marker:

 - we pass both to next_match(), which takes care to look at only the
   bytes we specified

Thinking aloud, next_match() calls match_next_pattern() which takes eol
as non-const and passes it to match_one_pattern(). And that calls
strip_timestamp(), which would be non-const, were it not the previous
patch. So I think this conversion is safe.

To be a little nit-picky: this move would be OK even without the change
to strip_timestamp(). The question is whether any of those sub-calls
actually looks past the "eol" pointer we give it.

I didn't dig all the way down through the complete call-stack in an
exhaustive way. But after having looked at the related functions when
changing their const-ness elsewhere in the series, they'd have to be
ignoring the "eol" parameter for it to be a problem. The irony, of
course, is that they did ignore this parameter at one point! Because
they'd all eventually end in regexec(), which would happily read past
our "eol".

So really, all of this is predicated on those sub-functions behaving
sensibly. I think they do. But if we found that they didn't, I'd much
rather know that and fix them than live with this "this NUL may or may
not be important" state forever.

quoted

 - we pass the line to output_color() without its matching eol marker.
   However, we do use the "match" struct we got from next_match() to
   tell it how many bytes to look at (which can never exceed the string
   we passed it

Yep, makes sense. The patch looks good and matches your description
here.

Thanks for looking it over (my nitpick aside). :)

-Peff