git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: shejialuo <shejialuo@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 4/7] string-list: optionally trim string pieces split by string_list_split*()
Date: Fri, 1 Aug 2025 12:04:54 +0800	[thread overview]
Message-ID: <aIw85gIurfEhvuPC@mbp> (raw)
In-Reply-To: <xmqqcy9fog8x.fsf@gitster.g>

On Thu, Jul 31, 2025 at 08:47:10PM -0700, Junio C Hamano wrote:
> shejialuo <shejialuo@gmail.com> writes:
> 
> > On Thu, Jul 31, 2025 at 03:46:03PM -0700, Junio C Hamano wrote:
> >>  static int split_string(struct string_list *list, const char *string, const char *delim,
> >> -			int maxsplit, int in_place)
> >> +			int maxsplit, int in_place, unsigned flags)
> >>  {
> >>  	int count = 0;
> >>  	const char *p = string;
> >> @@ -320,12 +327,18 @@ static int split_string(struct string_list *list, const char *string, const char
> >>  	for (;;) {
> >>  		char *end;
> >>  
> >> +		if (flags & STRING_LIST_SPLIT_TRIM) {
> >> +			/* ltrim */
> >> +			while (*p && isspace(*p))
> >> +				p++;
> >> +		}
> >> +
> >>  		if (0 <= maxsplit && maxsplit <= count)
> >>  			end = NULL;
> >>  		else
> >>  			end = strpbrk(p, delim);
> >>  
> >
> > In `append_one`, we would tell whether `end` is NULL. I somehow feel
> > strange why we need to do that in `append_one`. Should we just set `end`
> > to be `p + strlen(p)` when `end` is NULL. And then we could do rtrim
> > inside this function instead of `append_one` to avoid passing "flags" to
> > `append_one`.
> 
> Sorry, but I do not see why such an alternative design is a better
> idea.  The helper function's purpose is to stuff the substring at
> [p..end), possibly after rtrimming, to the list.  You could compute
> rtrim in the caller, but that would make the logic here more complex
> (at least, you'd need to introduce yet another variable similar to
> "end" that points at the real tail of the string, and you cannot
> reuse "end" for it, because of the exit condition you see below).
> 

I agree with you that we would introduce another variable. However, the
thing I quite dislike is that we do ltrim inside the current function
and we do rtrim inside `append_one`.

My thinking is that we should handle the [p, end) string in the same
place. We could either decide to drop the string or change the string in
the same place. However, at now, the logic happens at two different
places, which is my concern.

  reply	other threads:[~2025-08-01  4:04 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-31  6:39 [PATCH 0/5] string_list_split*() updates Junio C Hamano
2025-07-31  6:39 ` [PATCH 1/5] string-list: report programming error with BUG Junio C Hamano
2025-07-31 19:33   ` Eric Sunshine
2025-07-31 22:16     ` Junio C Hamano
2025-07-31  6:39 ` [PATCH 2/5] string-list: align string_list_split() with its _in_place() counterpart Junio C Hamano
2025-07-31 19:36   ` Eric Sunshine
2025-07-31  6:39 ` [PATCH 3/5] string-list: unify string_list_split* functions Junio C Hamano
2025-07-31  6:39 ` [PATCH 4/5] string-list: optionally trim string pieces split by string_list_split() Junio C Hamano
2025-07-31  6:39 ` [PATCH 5/5] diff: simplify parsing of diff.colormovedws Junio C Hamano
2025-07-31 19:45   ` Eric Sunshine
2025-07-31 22:45 ` [PATCH v2 0/7] string_list_split*() updates Junio C Hamano
2025-07-31 22:46   ` [PATCH v2 1/7] string-list: report programming error with BUG Junio C Hamano
2025-07-31 22:46   ` [PATCH v2 2/7] string-list: align string_list_split() with its _in_place() counterpart Junio C Hamano
2025-08-01  2:33     ` shejialuo
2025-08-01  3:43       ` Junio C Hamano
2025-08-01  3:55         ` shejialuo
2025-08-01 23:10           ` Junio C Hamano
2025-07-31 22:46   ` [PATCH v2 3/7] string-list: unify string_list_split* functions Junio C Hamano
2025-08-01  3:00     ` shejialuo
2025-07-31 22:46   ` [PATCH v2 4/7] string-list: optionally trim string pieces split by string_list_split*() Junio C Hamano
2025-08-01  3:18     ` shejialuo
2025-08-01  3:47       ` Junio C Hamano
2025-08-01  4:04         ` shejialuo [this message]
2025-08-01 23:09           ` Junio C Hamano
2025-08-02  1:51             ` shejialuo
2025-08-01  8:47     ` Patrick Steinhardt
2025-08-01 16:26       ` Junio C Hamano
2025-07-31 22:46   ` [PATCH v2 5/7] diff: simplify parsing of diff.colormovedws Junio C Hamano
2025-08-01  8:47     ` Patrick Steinhardt
2025-07-31 22:46   ` [PATCH v2 6/7] string-list: optionally omit empty string pieces in string_list_split*() Junio C Hamano
2025-07-31 22:54     ` Eric Sunshine
2025-08-01  3:33     ` shejialuo
2025-08-01  8:47     ` Patrick Steinhardt
2025-08-01 16:38       ` Junio C Hamano
2025-07-31 22:46   ` [PATCH v2 7/7] string-list: split-then-remove-empty can be done while splitting Junio C Hamano
2025-08-01  8:47     ` Patrick Steinhardt
2025-08-01 22:04   ` [PATCH v3 0/7] string_list_split*() updates Junio C Hamano
2025-08-01 22:04     ` [PATCH v3 1/7] string-list: report programming error with BUG Junio C Hamano
2025-08-01 22:04     ` [PATCH v3 2/7] string-list: align string_list_split() with its _in_place() counterpart Junio C Hamano
2025-08-02  8:22       ` Jeff King
2025-08-02 16:34         ` Junio C Hamano
2025-08-02 18:38           ` Jeff King
2025-08-01 22:04     ` [PATCH v3 3/7] string-list: unify string_list_split* functions Junio C Hamano
2025-08-01 22:04     ` [PATCH v3 4/7] string-list: optionally trim string pieces split by string_list_split*() Junio C Hamano
2025-08-02  8:26       ` Jeff King
2025-08-02 16:38         ` Junio C Hamano
2025-08-02 18:39           ` Jeff King
2025-08-01 22:04     ` [PATCH v3 5/7] diff: simplify parsing of diff.colormovedws Junio C Hamano
2025-08-01 22:04     ` [PATCH v3 6/7] string-list: optionally omit empty string pieces in string_list_split*() Junio C Hamano
2025-08-01 22:04     ` [PATCH v3 7/7] string-list: split-then-remove-empty can be done while splitting Junio C Hamano
2025-08-03  6:52     ` [PATCH v4 0/7] string_list_split*() updates Junio C Hamano
2025-08-03  6:52       ` [PATCH v4 1/7] string-list: report programming error with BUG Junio C Hamano
2025-08-03  6:52       ` [PATCH v4 2/7] string-list: align string_list_split() with its _in_place() counterpart Junio C Hamano
2025-08-03  6:52       ` [PATCH v4 3/7] string-list: unify string_list_split* functions Junio C Hamano
2025-08-03  6:52       ` [PATCH v4 4/7] string-list: optionally trim string pieces split by string_list_split*() Junio C Hamano
2025-08-03  6:52       ` [PATCH v4 5/7] diff: simplify parsing of diff.colormovedws Junio C Hamano
2025-08-03  6:52       ` [PATCH v4 6/7] string-list: optionally omit empty string pieces in string_list_split*() Junio C Hamano
2025-08-03  6:52       ` [PATCH v4 7/7] string-list: split-then-remove-empty can be done while splitting Junio C Hamano
2025-08-04  6:24       ` [PATCH v4 0/7] string_list_split*() updates Patrick Steinhardt
2025-08-03  6:52     ` [PATCH v3 00/12] do not overuse strbuf_split*() Junio C Hamano
2025-08-03  6:52       ` [PATCH v3 01/12] wt-status: avoid strbuf_split*() Junio C Hamano
2025-08-03  6:52       ` [PATCH v3 02/12] clean: do not pass strbuf by value Junio C Hamano
2025-08-03  6:52       ` [PATCH v3 03/12] clean: do not use strbuf_split*() [part 1] Junio C Hamano
2025-08-03  6:52       ` [PATCH v3 04/12] clean: do not pass the whole structure when it is not necessary Junio C Hamano
2025-08-03  6:52       ` [PATCH v3 05/12] clean: do not use strbuf_split*() [part 2] Junio C Hamano
2025-08-03  6:52       ` [PATCH v3 06/12] merge-tree: do not use strbuf_split*() Junio C Hamano
2025-08-03  6:52       ` [PATCH v3 07/12] notes: " Junio C Hamano
2025-08-03  6:53       ` [PATCH v3 08/12] config: do not use strbuf_split() Junio C Hamano
2025-08-03  6:53       ` [PATCH v3 09/12] environment: do not use strbuf_split*() Junio C Hamano
2025-08-03  6:53       ` [PATCH v3 10/12] sub-process: " Junio C Hamano
2025-08-03  6:53       ` [PATCH v3 11/12] trace2: trim_trailing_newline followed by trim is a no-op Junio C Hamano
2025-08-03  6:53       ` [PATCH v3 12/12] trace2: do not use strbuf_split*() Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aIw85gIurfEhvuPC@mbp \
    --to=shejialuo@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).