All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, "Jan Pokorný" <poki@fnusa.cz>,
	"Taylor Blau" <me@ttaylorr.com>
Subject: Re: [PATCH 1/4] repack: convert "names" util bitfield to array
Date: Fri, 21 Oct 2022 15:19:55 -0700	[thread overview]
Message-ID: <xmqqtu3wizuc.fsf@gitster.g> (raw)
In-Reply-To: <Y1MSWAx+baTklfLL@coredump.intra.peff.net> (Jeff King's message of "Fri, 21 Oct 2022 17:42:48 -0400")

Jeff King <peff@peff.net> writes:

> We keep a string_list "names" containing the hashes of packs generated
> on our behalf by pack-objects. The util field of each item is treated as
> a bitfield that tells us which extensions (.pack, .idx, .rev, etc) are
> present for each name.
>
> Let's switch this to allocating a real array. That will give us room in
> a future patch to store more data than just a single bit per extension.
> And it makes the code a little easier to read, as we avoid casting back
> and forth between uintptr_t and a void pointer.
>
> Since the only thing we're storing is an array, we could just allocate
> it directly. But instead I've put it into a named struct here. That
> further increases readability around the casts, and in particular helps
> differentiate us from other string_lists in the same file which use
> their util field differently. E.g., the existing_*_packs lists still do
> bit-twiddling, but their bits have different meaning than the ones in
> "names". This makes it hard to grep around the code to see how the util
> fields are used; now you can look for "generated_pack_data".
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  builtin/repack.c | 22 ++++++++++++++--------
>  1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/builtin/repack.c b/builtin/repack.c
> index a5bacc7797..8e71230bf7 100644
> --- a/builtin/repack.c
> +++ b/builtin/repack.c
> @@ -247,11 +247,15 @@ static struct {
>  	{".idx"},
>  };
>  
> -static unsigned populate_pack_exts(char *name)
> +struct generated_pack_data {
> +	char exts[ARRAY_SIZE(exts)];
> +};

OK, so instead of a single "unsigned" word holding six bits (the
number of elements in the exts[] array), we have one byte per the
file extension.  Since ...

> +static struct generated_pack_data *populate_pack_exts(const char *name)
>  {
>  	struct stat statbuf;
>  	struct strbuf path = STRBUF_INIT;
> -	unsigned ret = 0;
> +	struct generated_pack_data *data = xcalloc(1, sizeof(*data));

... this is allocated a real piece of storage and the function
returns a pointer to it, ...

> -		item->util = (void *)(uintptr_t)populate_pack_exts(item->string);
> +		item->util = populate_pack_exts(item->string);

... we no longer need to cast but the value can go straight to the
.util member, and ...

> -	string_list_clear(&names, 0);
> +	string_list_clear(&names, 1);

... we now need to free these structs pointed at by the .util
member.

All make sense.

  reply	other threads:[~2022-10-21 22:20 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-21 21:41 [PATCH 0/4] repack tempfile-cleanup signal deadlock Jeff King
2022-10-21 21:42 ` [PATCH 1/4] repack: convert "names" util bitfield to array Jeff King
2022-10-21 22:19   ` Junio C Hamano [this message]
2022-10-21 23:10   ` Taylor Blau
2022-10-21 23:29     ` Jeff King
2022-10-21 23:35       ` Junio C Hamano
2022-10-21 23:43         ` Jeff King
2022-10-21 23:51           ` Junio C Hamano
2022-10-22  0:12             ` Jeff King
2022-10-21 21:43 ` [PATCH 2/4] repack: populate extension bits incrementally Jeff King
2022-10-21 23:20   ` Taylor Blau
2022-10-21 23:34     ` Jeff King
2022-10-21 23:41       ` Taylor Blau
2022-10-21 23:42       ` Jeff King
2022-10-21 21:46 ` [PATCH 3/4] repack: use tempfiles for signal cleanup Jeff King
2022-10-21 22:30   ` Junio C Hamano
2022-10-21 23:24     ` Jeff King
2022-10-21 23:45       ` Taylor Blau
2022-10-22  0:12         ` Jeff King
2022-10-22  0:11       ` Jeff King
2022-10-21 21:48 ` [PATCH 4/4] repack: drop remove_temporary_files() Jeff King
2022-10-21 23:51   ` Taylor Blau
2022-10-22  0:21 ` [PATCH v2 0/5] repack tempfile-cleanup signal deadlock Jeff King
2022-10-22  0:21   ` [PATCH v2 1/5] repack: convert "names" util bitfield to array Jeff King
2022-10-22  0:21   ` [PATCH v2 2/5] repack: populate extension bits incrementally Jeff King
2022-10-22  0:21   ` [PATCH v2 3/5] repack: expand error message for missing pack files Jeff King
2022-10-22  0:21   ` [PATCH v2 4/5] repack: use tempfiles for signal cleanup Jeff King
2022-10-22 20:35     ` Jeff King
2022-10-23  0:14       ` Junio C Hamano
2022-10-23 17:00         ` Jeff King
2022-10-23 18:08           ` Junio C Hamano
2022-10-23 20:55             ` Jeff King
2022-10-23 21:48               ` Junio C Hamano
2022-10-22  0:21   ` [PATCH v2 5/5] repack: drop remove_temporary_files() Jeff King

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=xmqqtu3wizuc.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=peff@peff.net \
    --cc=poki@fnusa.cz \
    /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.