All of lore.kernel.org
 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 2/7] string-list: align string_list_split() with its _in_place() counterpart
Date: Fri, 1 Aug 2025 11:55:14 +0800	[thread overview]
Message-ID: <aIw6ojvvDWLPllG7@mbp> (raw)
In-Reply-To: <xmqqikj7ogf7.fsf@gitster.g>

On Thu, Jul 31, 2025 at 08:43:24PM -0700, Junio C Hamano wrote:
> shejialuo <shejialuo@gmail.com> writes:
> 
> > On Thu, Jul 31, 2025 at 03:46:01PM -0700, Junio C Hamano wrote:
> >> diff --git a/setup.c b/setup.c
> >> index 6f52dab64c..b9f5eb8b51 100644
> >> --- a/setup.c
> >> +++ b/setup.c
> >> @@ -1460,8 +1460,9 @@ static enum discovery_result setup_git_directory_gently_1(struct strbuf *dir,
> >>  
> >>  	if (env_ceiling_dirs) {
> >>  		int empty_entry_found = 0;
> >> +		static const char path_sep[] = { PATH_SEP, '\0' };
> >>  
> >
> > I am a little confused why we need to use `static`? Would this function
> > be called many times?
> 
> I actually am confused why you would want anything other than static
> here.  Writing this way would allow the compiler to realize that the
> array can be prepared at compile time, without need to do anything
> at runtime.  If you made it non static, the runtime code would
> allocate two bytes worth of memory on stack, and stuff these two
> byte values there, each time this block is entered, which would be
> at least once.
> 

Sorry to make you confused. Because there are some other changes where
you don't use `static`. That's the main reason why I ask this question.

--- a/t/helper/test-path-utils.c
+++ b/t/helper/test-path-utils.c
@@ -348,6 +348,7 @@ int cmd__path_utils(int argc, const char **argv)
 	if (argc == 4 && !strcmp(argv[1], "longest_ancestor_length")) {
 		int len;
 		struct string_list ceiling_dirs = STRING_LIST_INIT_DUP;
+		const char path_sep[] = { PATH_SEP, '\0' };
 		char *path = xstrdup(argv[2]);

> > And I have a design question: by using "PATH_SEP", we need to convert
> > this character to be string. Should we create a new variable named
> > "PATH_SEP_STR" or whatever to do that?
> 
> Sorry, but I do not understand the question.  You want to see
> something like
> 
> 	#define PATH_SEP_STR "/"
> 
> you mean?  I do not offhand see why anybody would want to do so.
> 

Yes, that's my question. Because I see that we would define `path_sep`
array in many place, so I wonder whether we could use such macro.

  reply	other threads:[~2025-08-01  3:55 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 [this message]
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
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=aIw6ojvvDWLPllG7@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.