From: Junio C Hamano <gitster@pobox.com>
To: Olamide Caleb Bello <belkid98@gmail.com>
Cc: git@vger.kernel.org, usmanakinyemi202@gmail.com,
christian.couder@gmail.com, Junio Hamano <gitster@pobox.com>
Subject: Re: [Outreachy PATCH v3 2/2] gpg-interface: use string_list_split*() instead of strbuf_split*()
Date: Sun, 19 Oct 2025 09:00:36 -0700 [thread overview]
Message-ID: <xmqqikga3mqj.fsf@gitster.g> (raw)
In-Reply-To: <9a6eb6ff8b92a94de990303cc78026029a669cf8.1760869186.git.belkid98@gmail.com> (Olamide Caleb Bello's message of "Sun, 19 Oct 2025 12:07:43 +0000")
Olamide Caleb Bello <belkid98@gmail.com> writes:
> In get_default_ssh_signing_key(), the default ssh signing key is
> retrieved in `key_stdout`, which is then split using
> strbuf_split_max() into two tokens
>
> The string in `key_stdout` is then split using strbuf_split_max() into
> two tokens at a new line and the first token is returned as a `char *`
> and not a strbuf.
> This makes the function lack the use of strbuf API as no edits are
> performed on the split tokens.
>
> Replace strbuf_split_max() with string_list_split_in_place() for
> simplicity
>
> Note that strbuf_split_max() uses `2` to indicate the number of tokens
> to extract from the string, while string_list_split_in_place() uses `1`
> to specify the number of times the split will be done on the string,
> so 1 gives 2 tokens as it is in the original instance.
>
> string_list_split_in_place() returns the number of substrings added to the
> list keys.items, so we check that at least one substring is added to the
> list since we just want to return the first substring.
>
> Signed-off-by: Olamide Caleb Bello <belkid98@gmail.com>
> Reported-by: Junio Hamano <gister@pobox.com>
> Helped-by: Christian Couder <christian.couder@gmail.com>
> ---
> gpg-interface.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
Exactly the same comment as [1/2] (including the part about the
first paragraph seemingly missing something at the end ;-).
Also, it may not be necessary to highlight the quirky way the
string_list_split*() function counts numbers again, as it is done in
the previous patch so readers have already been warned against it.
And the same comment applies about the round-about way the original
was written in the first place. Isn't it merely the matter of
finding the first line-feed and making a copy of a string up to that
point?
Perhaps we would be better off if we revise the theme of the topic
"use string_list_split*() to replace strbuf_split*()" to "do not use
misdesigned strbuf_split*() function" and do the rewrite without
using string_list_split*() after all? It may result in a much
cleaner and simpler code at the end.
Thanks.
> diff --git a/gpg-interface.c b/gpg-interface.c
> index cb182f4c11..3b9d85a5ef 100644
> --- a/gpg-interface.c
> +++ b/gpg-interface.c
> @@ -862,7 +862,7 @@ static char *get_default_ssh_signing_key(void)
> struct child_process ssh_default_key = CHILD_PROCESS_INIT;
> int ret = -1;
> struct strbuf key_stdout = STRBUF_INIT, key_stderr = STRBUF_INIT;
> - struct strbuf **keys;
> + struct string_list keys = STRING_LIST_INIT_NODUP;
> char *key_command = NULL;
> const char **argv;
> int n;
> @@ -884,19 +884,19 @@ static char *get_default_ssh_signing_key(void)
> &key_stderr, 0);
>
> if (!ret) {
> - keys = strbuf_split_max(&key_stdout, '\n', 2);
> - if (keys[0] && is_literal_ssh_key(keys[0]->buf, &literal_key)) {
> + if (string_list_split_in_place(&keys, key_stdout.buf, "\n", 1) > 0 &&
> + is_literal_ssh_key(keys.items[0].string, &literal_key)) {
> /*
> * We only use `is_literal_ssh_key` here to check validity
> * The prefix will be stripped when the key is used.
> */
> - default_key = strbuf_detach(keys[0], NULL);
> + default_key = xstrdup(keys.items[0].string);
> } else {
> warning(_("gpg.ssh.defaultKeyCommand succeeded but returned no keys: %s %s"),
> key_stderr.buf, key_stdout.buf);
> }
>
> - strbuf_list_free(keys);
> + string_list_clear(&keys, 0);
> } else {
> warning(_("gpg.ssh.defaultKeyCommand failed: %s %s"),
> key_stderr.buf, key_stdout.buf);
next prev parent reply other threads:[~2025-10-19 16:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-19 12:07 [Outreachy PATCH v3 0/2] gpg-interface.c: use string_list_split*() instead of strbuf_split*() Olamide Caleb Bello
2025-10-19 12:07 ` [Outreachy PATCH v3 1/2] gpg-interface: replace strbuf_split*() with string_list_split*() Olamide Caleb Bello
2025-10-19 15:52 ` Junio C Hamano
2025-10-20 6:32 ` Bello Olamide
2025-10-20 15:09 ` Junio C Hamano
2025-10-20 16:31 ` Junio C Hamano
2025-10-20 18:15 ` Bello Olamide
2025-10-20 18:12 ` Bello Olamide
2025-10-20 16:45 ` Kristoffer Haugsbakk
2025-10-20 18:25 ` Bello Olamide
2025-10-20 18:37 ` Kristoffer Haugsbakk
2025-10-20 18:50 ` Bello Olamide
2025-10-19 12:07 ` [Outreachy PATCH v3 2/2] gpg-interface: use string_list_split*() instead of strbuf_split*() Olamide Caleb Bello
2025-10-19 16:00 ` Junio C Hamano [this message]
2025-10-20 8:15 ` Bello Olamide
2025-10-20 15:18 ` Junio C Hamano
2025-10-20 19:02 ` Bello Olamide
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=xmqqikga3mqj.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=belkid98@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=usmanakinyemi202@gmail.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).