From: Junio C Hamano <gitster@pobox.com>
To: "Rubén Justo" <rjusto@gmail.com>
Cc: Git List <git@vger.kernel.org>, Patrick Steinhardt <ps@pks.im>
Subject: Re: [PATCH v2] strvec: `strvec_splice()` to a statically initialized vector
Date: Wed, 04 Dec 2024 09:09:36 +0900 [thread overview]
Message-ID: <xmqqplm871hb.fsf@gitster.g> (raw)
In-Reply-To: <5bea9f20-eb0d-409d-8f37-f20697d6ce14@gmail.com> ("Rubén Justo"'s message of "Tue, 3 Dec 2024 20:47:43 +0100")
Rubén Justo <rjusto@gmail.com> writes:
> Note that an empty strvec instance (with zero elements) does not
> necessarily need to be an instance initialized with the singleton.
Correct.
When (vec.nr == 0), vec.v may be pointing at
(1) an allocated piece of memory, if the strvec was previously used
to hold some strings; or
(2) singleton array with NULL.
and vec.v[0] is NULL. This is to allow you to pass vec.v[] as a
NULL terminated list of (char *) (aka argv[][]) to functions.
That can be said a bit differently and more concisely like so:
A strvec instance with no elements can have its member .v
pointing at empty_strvec[] or pointing at an allocated piece of
memory, and either way .v[0] has NULL in it, to allow you to
always treat vec.v[] as a NULL terminated array of strings, even
immediately after initialization.
and then you can lose the strvec_pop() illustration below that talks
about an allocated piece of memory that was previously used.
> The recently introduced `strvec_splice()` API is expected to be
> normally used with non-empty strvec's.
It is perfectly sensible to expect that you can splice your stuff
into an empty strvec, so all this sentence is saying is that a
strvec is more often non-empty than empty. I'd recommend dropping
this sentence.
Something like
When growing a strvec, we'd use a realloc() call on its .v[]
member, but a care must be taken when it is pointing at
empty_strvec[] and is not pointing at an allocated piece of
memory. strvec_push_nodup() and strvec_push() correctly do so.
The recently added strvec_splice() forgot to.
should be sufficient. Notice that I didn't have to invent a new
term "empty-singleton" at all ;-).
Thanks.
next prev parent reply other threads:[~2024-12-04 0:09 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-29 17:23 [PATCH] strvec: `strvec_splice()` to a statically initialized vector Rubén Justo
2024-12-02 1:49 ` Junio C Hamano
2024-12-02 22:01 ` Rubén Justo
2024-12-02 12:54 ` Patrick Steinhardt
2024-12-03 19:47 ` [PATCH v2] " Rubén Justo
2024-12-04 0:09 ` Junio C Hamano [this message]
2024-12-04 1:08 ` Rubén Justo
2024-12-04 7:41 ` Junio C Hamano
2024-12-04 8:46 ` Rubén Justo
2024-12-04 8:50 ` Rubén Justo
2024-12-04 10:15 ` Junio C Hamano
2024-12-09 1:32 ` Junio C Hamano
2024-12-09 1:35 ` Junio C Hamano
2024-12-09 1:56 ` Junio C Hamano
2024-12-09 2:15 ` Jeff King
2024-12-09 7:33 ` Junio C Hamano
2024-12-09 22:42 ` Rubén Justo
2024-12-04 11:26 ` karthik nayak
2024-12-04 22:22 ` Rubén Justo
2024-12-06 11:33 ` karthik nayak
2024-12-04 22:44 ` [PATCH v3] " Rubén Justo
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=xmqqplm871hb.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
--cc=rjusto@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 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.