From: Junio C Hamano <gitster@pobox.com>
To: Olamide Caleb Bello <belkid98@gmail.com>
Cc: git@vger.kernel.org, christian.couder@gmail.com,
usmanakinyemi202@gmail.com
Subject: Re: [Outreachy PATCH v2 1/2] gpg-interface: replace strbuf_split_max() with string_list_split()
Date: Thu, 16 Oct 2025 10:27:16 -0700 [thread overview]
Message-ID: <xmqqms5q4v0r.fsf@gitster.g> (raw)
In-Reply-To: <818ca6b104cf25ebe4c60145d046029f057f4db1.1760571220.git.belkid98@gmail.com> (Olamide Caleb Bello's message of "Thu, 16 Oct 2025 01:03:53 +0000")
Olamide Caleb Bello <belkid98@gmail.com> writes:
> @@ -821,7 +822,7 @@ static char *get_ssh_key_fingerprint(const char *signing_key)
> struct child_process ssh_keygen = CHILD_PROCESS_INIT;
> int ret = -1;
> struct strbuf fingerprint_stdout = STRBUF_INIT;
> - struct strbuf **fingerprint;
> + struct string_list split = STRING_LIST_INIT_DUP;
> char *fingerprint_ret;
> const char *literal_key = NULL;
>
> @@ -845,13 +846,12 @@ static char *get_ssh_key_fingerprint(const char *signing_key)
> die_errno(_("failed to get the ssh fingerprint for key '%s'"),
> signing_key);
>
> - fingerprint = strbuf_split_max(&fingerprint_stdout, ' ', 3);
> - if (!fingerprint[1])
> + if (string_list_split(&split, fingerprint_stdout.buf, " ", 2) != 3)
The original splits the thing into upto 3 pieces, but only complains
if the second piece is NULL (i.e. we said "up to 3", but there was
not even one place to split, and the request to split_max gave the
one thing as one piece). IOW, the original code will happily accept
if the finterprint_stdout is split only into two, not three.
The updated code asks to split at at most two places (yes, it is a
confusing API, but if you split at two places, you will end up with
three pieces), and insists that the split results in three pieces.
So the rewrite tightens the error condition.
Was the original code too loose in detecting an error, and does this
patch tightens the condition "while at it"? Or was the original
code correct to expect that there are legitimate cases where the
payload in finterprint_stdout only contains two pieces, and it was
the right thing to do to accept when fingerprint[1] is not NULL but
fingerprint[2] is NULL?
This is a genuine question. I haven't studied the code path to
reach this point in the code flow, I don't know what the data in
fingerprint_stdout is supposed to look like, so I do not know the
answer to the question (in other words, it cannot be an oblique way
to point out that the updated code is wrong or anything like that).
> die_errno(_("failed to get the ssh fingerprint for key '%s'"),
> signing_key);
>
> - fingerprint_ret = strbuf_detach(fingerprint[1], NULL);
> - strbuf_list_free(fingerprint);
> + fingerprint_ret = xstrdup(split.items[1].string);
> + string_list_clear(&split, 0);
> strbuf_release(&fingerprint_stdout);
Since this code releases fingerprint_stdout before leaving, and
returns a fresh copy of a split piece, it may make more sense to use
string_list_split_in_place(), which does not have to allocate extra
strings while it does its work, unlike string_list_split().
> return fingerprint_ret;
> }
next prev parent reply other threads:[~2025-10-16 17:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-16 1:03 [Outreachy PATCH v2 0/2] gpg-interface.c: use string_list_split() instead of strbuf_split_max() Olamide Caleb Bello
2025-10-16 1:03 ` [Outreachy PATCH v2 1/2] gpg-interface: replace strbuf_split_max() with string_list_split() Olamide Caleb Bello
2025-10-16 17:27 ` Junio C Hamano [this message]
2025-10-17 9:15 ` Christian Couder
2025-10-17 10:07 ` Bello Olamide
2025-10-17 18:47 ` Junio C Hamano
2025-10-17 10:53 ` Bello Olamide
2025-10-16 1:03 ` [Outreachy PATCH v2 2/2] gpg-interface: use string_list_split() instead of strbuf_split_max() Olamide Caleb Bello
2025-10-17 7:58 ` [Outreachy PATCH v2 0/2] gpg-interface.c: " Christian Couder
2025-10-17 9:54 ` 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=xmqqms5q4v0r.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).