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

Re: [PATCH v1 2/2] list-objects-filter-options: avoid strbuf_split_str()

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 9, 2026, 15:38 UTC
Message-ID
<xmqqjyvl57yv.fsf@gitster.g>
In-Reply-To
<20260308180359.31188-3-deveshigurgaon@gmail.com>
Deveshi Dwivedi <deveshigurgaon@gmail.com> writes:
Show 15 quoted lines
> parse_combine_filter() splits a combine: filter spec at '+' using
> strbuf_split_str(), which yields an array of strbufs with the
> delimiter left at the end of each non-final piece.  The code then
> mutates each non-final piece to strip the trailing '+' before parsing.
>
> Allocating an array of strbufs is unnecessary.  The function processes
> one sub-spec at a time and does not use strbuf editing on the pieces.
> The two helpers it calls, has_reserved_character() and
> parse_combine_subfilter(), only read the string content of the strbuf
> they receive.
>
> Walk the input string directly with strchr() to find each '+'.  Copy
> each sub-spec into a temporary buffer and strip the '+' only when
> another sub-spec follows.  Change the helpers to take const char *
> instead of struct strbuf *.

Makes sense. Instead of finding '+' and making many small copies piecemeal, you could make a single copy of "const char *arg" once, walk that string using strchr() looking for the next '+', and replace '+' with '\0' before processing the current piece and iterate, which may reduce the need for many small allocations and deallocations, but I do not know if it is worth it. Benchmarking it would not yield measurable difference, I suspect.

Show 15 quoted lines
> +	while (*p && !result) {
> +		const char *sep = strchr(p, '+');
> +		size_t len = sep ? (size_t)(sep - p + 1) : strlen(p);
> +		char *sub = xmemdupz(p, len);
> +
> +		/* strip '+' separator, but only when more sub-specs follow */
> +		if (sep && *(sep + 1))
> +			sub[len - 1] = '\0';
> +
> +		result = parse_combine_subfilter(filter_options, sub, errbuf);
> +		free(sub);
> +		if (!sep)
> +			break;
> +		p = sep + 1;
>  	}

Hmph, would this loop handle a trailing '+' the same way as before, e.g., "combine:tree:2+"? The original would have split the string into ["tree:2+", ""] and the last call to parse_combine_subfilter() would have been made with an empty string. The new code does not make that last call with an empty string. Perhaps the differences do not matter? I dunno.

Other than that, nice to see one fewer use of "splitting into an array of strbuf" pattern.

Thanks.
Previous: Deveshi DwivediNext: Jeff King
Message 6 of 8 in “avoid unnecessary strbuf_split*() and strbuf-by-value usage”
  1. 0/2 avoid unnecessary strbuf_split*() and strbuf-by-value usageDeveshi Dwivedi, Mar 8, 2026
  2. 1/2 worktree: do not pass strbuf by valueDeveshi Dwivedi, Mar 8, 2026
  3. Junio C HamanoMar 9, 2026
  4. coccinelle to catch pass-by-value?, was: [PATCH v1 1/2] worktree: do not pass strbuf by valueJeff King, Mar 9, 2026
  5. 2/2 list-objects-filter-options: avoid strbuf_split_str()Deveshi Dwivedi, Mar 8, 2026
  6. Junio C HamanoMar 9, 2026
  7. Jeff KingMar 9, 2026
  8. Jeff KingMar 9, 2026

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.