git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 6/9] reftable/stack: return stack segments directly
Date: Mon, 13 Oct 2025 13:10:40 +0200	[thread overview]
Message-ID: <aOzeMLVx6P_AbxCQ@pks.im> (raw)
In-Reply-To: <CAOLa=ZSfiD4KTSMyc2WW4oC2zyDO9CHmUWwnws3GhCdbtL4rAA@mail.gmail.com>

On Mon, Oct 13, 2025 at 02:01:15AM -0700, Karthik Nayak wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> >> diff --git a/reftable/stack.c b/reftable/stack.c
> >> index f91ce50bcd..9d9326ce0e 100644
> >> --- a/reftable/stack.c
> >> +++ b/reftable/stack.c
> >> @@ -1639,29 +1640,29 @@ static uint64_t *stack_table_sizes_for_compaction(struct reftable_stack *st)
> >>
> >>  	REFTABLE_CALLOC_ARRAY(sizes, st->merged->tables_len);
> >>  	if (!sizes)
> >> -		return NULL;
> >> +		return REFTABLE_OUT_OF_MEMORY_ERROR;
> >>
> >>  	for (size_t i = 0; i < st->merged->tables_len; i++)
> >>  		sizes[i] = st->tables[i]->size - overhead;
> >>
> >> -	return sizes;
> >> +	*seg = suggest_compaction_segment(sizes, st->merged->tables_len,
> >> +					  st->opts.auto_compaction_factor);
> >> +	reftable_free(sizes);
> >> +
> >> +	return 0;
> >>  }
> >>
> >>  int reftable_stack_auto_compact(struct reftable_stack *st)
> >>  {
> >>  	struct segment seg;
> >> -	uint64_t *sizes;
> >> +	int err = 0;
> >
> > The initialization is unnecessary.
> >
> 
> True, but I always think its nicer to define the base state like this.
> This makes it less error prone when/if the code is modified in the
> future. But doesn't really matter, so let me remove it.

The counterargument to this is that it doesn't give us any nice compiler
warnings if a specific return forgets to set the variable, so we may
return successfully by accident. If you leave this uninitialized then
the compiler warns you for every early return where you don't initialize
the variable. For all I can tell this warning is also quite reliable.

Patrick

  reply	other threads:[~2025-10-13 11:10 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-10 10:27 [PATCH 0/9] refs: add a '--required' flag to 'git refs optimize' Karthik Nayak
2025-10-10 10:27 ` [PATCH 1/9] refs: move to using the '.optimize' functions Karthik Nayak
2025-10-10 11:22   ` Patrick Steinhardt
2025-10-13  8:18     ` Karthik Nayak
2025-10-10 10:27 ` [PATCH 2/9] refs: cleanup code around optimization Karthik Nayak
2025-10-10 11:22   ` Patrick Steinhardt
2025-10-13  8:22     ` Karthik Nayak
2025-10-10 10:27 ` [PATCH 3/9] refs: rename 'pack_refs_opts' to 'optimize_refs_opts' Karthik Nayak
2025-10-10 11:22   ` Patrick Steinhardt
2025-10-13  8:52     ` Karthik Nayak
2025-10-10 10:27 ` [PATCH 4/9] t/pack-refs-tests: move the 'test_done' to callees Karthik Nayak
2025-10-10 11:22   ` Patrick Steinhardt
2025-10-13  8:54     ` Karthik Nayak
2025-10-10 10:27 ` [PATCH 5/9] t/t0450: split whitespace consistency check per subcommand Karthik Nayak
2025-10-10 10:27 ` [PATCH 6/9] reftable/stack: return stack segments directly Karthik Nayak
2025-10-10 11:22   ` Patrick Steinhardt
2025-10-13  9:01     ` Karthik Nayak
2025-10-13 11:10       ` Patrick Steinhardt [this message]
2025-10-10 10:27 ` [PATCH 7/9] reftable/stack: add function to check if optimization is required Karthik Nayak
2025-10-10 11:22   ` Patrick Steinhardt
2025-10-13  9:04     ` Karthik Nayak
2025-10-10 10:27 ` [PATCH 8/9] refs: add a `optimize_required` field to `struct ref_storage_be` Karthik Nayak
2025-10-10 11:22   ` Patrick Steinhardt
2025-10-13  9:46     ` Karthik Nayak
2025-10-10 10:27 ` [PATCH 9/9] refs: add a '--required' flag to 'git refs optimize' Karthik Nayak
2025-10-10 11:22   ` Patrick Steinhardt
2025-10-13 12:37     ` Karthik Nayak
2025-10-13 13:40     ` Junio C Hamano
2025-10-13 14:37       ` Junio C Hamano
2025-10-14 15:08         ` Karthik Nayak
2025-10-14 17:46           ` Junio C Hamano
2025-10-15  7:50             ` Srivastava, Nitin
2025-10-15  8:19             ` Karthik Nayak
2025-10-15  9:29               ` Karthik Nayak
2025-10-15 12:14                 ` Patrick Steinhardt
2025-10-15 20:17                   ` 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=aOzeMLVx6P_AbxCQ@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=karthik.188@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).