git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v5 2/2] pretty: colorize pattern matches in commit messages

From
Jeff King <peff@peff.net>
Date
Sep 17, 2021, 22:00 UTC
Message-ID
<YUUQA1qNCzY7Vx+j@coredump.intra.peff.net>
In-Reply-To
<WCKLZQ.YCP2HWKW7YBB2@effective-light.com>
On Fri, Sep 17, 2021 at 05:14:56PM -0400, Hamza Mahfooz wrote:
Show 23 quoted lines
> 
> On Fri, Sep 17 2021 at 03:10:12 AM -0400, Eric Sunshine
> <sunshine@sunshineco.com> wrote:
> > `buf` and `eol` seem like an accident waiting to happen...
> > 
> > >  +       line_color = opt->colors[GREP_COLOR_SELECTED];
> > >  +       match_color = opt->colors[GREP_COLOR_MATCH_SELECTED];
> > >  +
> > >  +       while (grep_next_match(opt, buf, eol, ctx, &match, field,
> > > eflags)) {
> > >  +               if (match.rm_so == match.rm_eo)
> > >  +                       break;
> > >  +
> > >  +               strbuf_grow(sb, strlen(line_color) +
> > > strlen(match_color) +
> > >  +                           (2 * strlen(GIT_COLOR_RESET)));
> > 
> > ... because strbuf_grow() may reallocate the underlying buffer, which
> > means that `buf` and `eol` will end up pointing at freed memory, which
> > will be accessed by the next call to grep_next_match().
> 
> I don't see how it's problematic, since `tmp_sb` isn't modified after `buf`
> is initialized (until strbuf_release() is called, of course).

Yes, you are correct. However, I do think the code would be much clearer if you skipped the strbuf entirely, like:

  char *line_as_string;
  ...
  line_as_string = xmemdupz(line, linelen);
  ...
  buf = line_as_string;
  eol = buf + linelen;
  ...
  free(line_as_string);

which makes it much clearer that you don't intend to modify it further (especially with all those other calls operating on the _other_ strbuf, it's hard to see immediately that this is the case).

The "as_string" name is assuming the purpose is to get a NUL-terminated string. I'm not sure why we need one, though, since we pass the buf/eol pointers to grep_next_match(). A comment above the xmemdupz() line might be a good place to explain that (which would help especially if the reasons change later and we can get rid of it).

-Peff
Previous: Hamza MahfoozNext: Eric Sunshine
Message 5 of 6 in “grep: refactor next_match() and match_one_pattern() for external use”
  1. 1/2 grep: refactor next_match() and match_one_pattern() for external useHamza Mahfooz, Sep 16, 2021
  2. 2/2 pretty: colorize pattern matches in commit messagesHamza Mahfooz, Sep 16, 2021
  3. Eric SunshineSep 17, 2021
  4. Hamza MahfoozSep 17, 2021
  5. Jeff KingSep 17, 2021
  6. Eric SunshineSep 17, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.