All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Carlo Arenas <carenas@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Eric Sunshine <sunshine@sunshineco.com>,
	git@vger.kernel.org
Subject: Re: [PATCH 3/5] reftable/stack: fix compiler warning due to missing braces
Date: Tue, 12 Aug 2025 11:27:47 +0200	[thread overview]
Message-ID: <aJsJE3UzKIVeg3di@pks.im> (raw)
In-Reply-To: <qruwf2zjl2uvf33mp4ajklvgx7wq7ctghu53rxzbgndfojudvh@ylr4otznu2og>

On Mon, Aug 11, 2025 at 09:18:09PM -0700, Carlo Arenas wrote:
> On Tue, Aug 05, 2025 at 06:49:45AM -0800, Patrick Steinhardt wrote:
> > On Mon, Aug 04, 2025 at 12:14:22PM -0700, Junio C Hamano wrote:
> > > Patrick Steinhardt <ps@pks.im> writes:
> > > 
> > > > Yeah, in general I'm also of the opinion that we shouldn't bother. But
> > > > in libgit2 we have pipelines that use such older compilers, and we don't
> > > > want to drop those for now. So I think we should treat the reftable
> > > > library specially, doubly so as this is the only instance that causes
> > > > problems.
> > > 
> > > Hmph.  Shouldn't there be some kind of "shim" layer where these
> > > things are defined per project convention and/or toolchain being
> > > used?  So when building for git proper, you'd use {0} just as
> > > everybody else do, but for others your include file supplied by that
> > > project would use something else (like {{0}} in this case)?  That
> > > kind of approach would be a better solution than open coding QSORT()
> > > in the longer term, for example.
> > 
> > We do have a shim layer, but I don't think it makes sense to use it for
> > every small piece. The intent of that layer is to paper over platform
> > differences that we cannot easily hide away in a generic fashion. So
> > things like mmap, random numbers, handling includes or registering
> > lockfiles via atexit(3p).
> > 
> > But I don't think it makes sense to use the shim layer for things like
> > `{0}` vs `{{0}}`
> 
> I think the suggestion for using a shim layer solution is relevant, because
> additionally to the compatibility issues of the zero initializer, you also
> need to take into consideration that the proposed solution will still trigger
> warnings when compiled as C++ (where {0} should be instead {}).

Do we even support compiling Git as C++?

> Why not do instead something like?

But this is fair indeed -- the definition is internal anyway and not
exposed to outside callers, so we can just as well use `memset()`.

Patrick

> diff --git a/reftable/stack.c b/reftable/stack.c
> index 4caf96aa1d..80ce8a7083 100644
> --- a/reftable/stack.c
> +++ b/reftable/stack.c
> @@ -704,8 +704,6 @@ struct reftable_addition {
>  	uint64_t next_update_index;
>  };
>  
> -#define REFTABLE_ADDITION_INIT {0}
> -
>  static int reftable_stack_init_addition(struct reftable_addition *add,
>  					struct reftable_stack *st,
>  					unsigned int flags)
> @@ -859,7 +857,7 @@ int reftable_stack_new_addition(struct reftable_addition **dest,
>  				unsigned int flags)
>  {
>  	int err = 0;
> -	struct reftable_addition empty = REFTABLE_ADDITION_INIT;
> +	static const struct reftable_addition empty;
>  
>  	REFTABLE_CALLOC_ARRAY(*dest, 1);
>  	if (!*dest)
> @@ -879,8 +877,11 @@ static int stack_try_add(struct reftable_stack *st,
>  					    void *arg),
>  			 void *arg)
>  {
> -	struct reftable_addition add = REFTABLE_ADDITION_INIT;
> -	int err = reftable_stack_init_addition(&add, st, 0);
> +	struct reftable_addition add;
> +	int err;
> +
> +	memset(&add, 0, sizeof(add));
> +	err = reftable_stack_init_addition(&add, st, 0);
>  	if (err < 0)
>  		goto done;
>  
> Carlo

  reply	other threads:[~2025-08-12  9:27 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-01 14:47 [PATCH 0/5] reftable: a couple of improvements for libgit2 Patrick Steinhardt
2025-08-01 14:47 ` [PATCH 1/5] reftable/writer: fix type used for number of records Patrick Steinhardt
2025-08-01 14:47 ` [PATCH 2/5] reftable/writer: drop Git-specific `QSORT()` macro Patrick Steinhardt
2025-08-01 14:47 ` [PATCH 3/5] reftable/stack: fix compiler warning due to missing braces Patrick Steinhardt
2025-08-01 19:19   ` Eric Sunshine
2025-08-04  6:03     ` Patrick Steinhardt
2025-08-04 19:14       ` Junio C Hamano
2025-08-05  4:49         ` Patrick Steinhardt
2025-08-12  4:18           ` Carlo Arenas
2025-08-12  9:27             ` Patrick Steinhardt [this message]
2025-08-12 14:37               ` Junio C Hamano
2025-08-01 14:47 ` [PATCH 4/5] reftable/stack: reorder code to avoid forward declarations Patrick Steinhardt
2025-08-01 14:47 ` [PATCH 5/5] reftable/stack: allow passing flags to `reftable_stack_add()` Patrick Steinhardt
2025-08-04  9:40 ` [PATCH v2 0/6] reftable: a couple of improvements for libgit2 Patrick Steinhardt
2025-08-04  9:40   ` [PATCH v2 1/6] reftable/writer: fix type used for number of records Patrick Steinhardt
2025-08-04  9:40   ` [PATCH v2 2/6] reftable/writer: drop Git-specific `QSORT()` macro Patrick Steinhardt
2025-08-04  9:40   ` [PATCH v2 3/6] reftable/stack: fix compiler warning due to missing braces Patrick Steinhardt
2025-08-04  9:40   ` [PATCH v2 4/6] reftable/stack: reorder code to avoid forward declarations Patrick Steinhardt
2025-08-11 19:10     ` Justin Tobler
2025-08-04  9:40   ` [PATCH v2 5/6] reftable/stack: allow passing flags to `reftable_stack_add()` Patrick Steinhardt
2025-08-11 19:34     ` Justin Tobler
2025-08-12  9:27       ` Patrick Steinhardt
2025-08-04  9:40   ` [PATCH v2 6/6] reftable/stack: handle outdated stacks when compacting Patrick Steinhardt
2025-08-11 20:04     ` Justin Tobler
2025-08-12  9:28       ` Patrick Steinhardt
2025-08-12  9:54 ` [PATCH v3 0/8] reftable: a couple of improvements for libgit2 Patrick Steinhardt
2025-08-12  9:54   ` [PATCH v3 1/8] reftable/writer: fix type used for number of records Patrick Steinhardt
2025-08-12  9:54   ` [PATCH v3 2/8] reftable/writer: drop Git-specific `QSORT()` macro Patrick Steinhardt
2025-08-12  9:54   ` [PATCH v3 3/8] reftable/stack: reorder code to avoid forward declarations Patrick Steinhardt
2025-08-12  9:54   ` [PATCH v3 4/8] reftable/stack: fix compiler warning due to missing braces Patrick Steinhardt
2025-08-12 16:51     ` Justin Tobler
2025-08-12  9:54   ` [PATCH v3 5/8] reftable/stack: allow passing flags to `reftable_stack_add()` Patrick Steinhardt
2025-08-12 16:59     ` Justin Tobler
2025-08-13  6:12       ` Patrick Steinhardt
2025-08-12  9:54   ` [PATCH v3 6/8] reftable/stack: handle outdated stacks when compacting Patrick Steinhardt
2025-08-12  9:54   ` [PATCH v3 7/8] reftable: don't second-guess errors from flock interface Patrick Steinhardt
2025-08-12 17:05     ` Justin Tobler
2025-08-12  9:54   ` [PATCH v3 8/8] refs/reftable: always reload stacks when creating lock Patrick Steinhardt
2025-08-12 17:12     ` Justin Tobler
2025-08-12 19:00   ` [PATCH v3 0/8] reftable: a couple of improvements for libgit2 Carlo Arenas
2025-08-13  6:11     ` Patrick Steinhardt
2025-08-13 14:23       ` Junio C Hamano
2025-08-13  6:25 ` [PATCH v4 " Patrick Steinhardt
2025-08-13  6:25   ` [PATCH v4 1/8] reftable/writer: fix type used for number of records Patrick Steinhardt
2025-08-13  6:25   ` [PATCH v4 2/8] reftable/writer: drop Git-specific `QSORT()` macro Patrick Steinhardt
2025-08-13  6:25   ` [PATCH v4 3/8] reftable/stack: reorder code to avoid forward declarations Patrick Steinhardt
2025-08-13  6:25   ` [PATCH v4 4/8] reftable/stack: fix compiler warning due to missing braces Patrick Steinhardt
2025-08-13  6:25   ` [PATCH v4 5/8] reftable/stack: allow passing flags to `reftable_stack_add()` Patrick Steinhardt
2025-08-13  6:25   ` [PATCH v4 6/8] reftable/stack: handle outdated stacks when compacting Patrick Steinhardt
2025-08-13  6:25   ` [PATCH v4 7/8] reftable: don't second-guess errors from flock interface Patrick Steinhardt
2025-08-13  6:25   ` [PATCH v4 8/8] refs/reftable: always reload stacks when creating lock Patrick Steinhardt
2025-08-13 14:38   ` [PATCH v4 0/8] reftable: a couple of improvements for libgit2 Justin Tobler

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=aJsJE3UzKIVeg3di@pks.im \
    --to=ps@pks.im \
    --cc=carenas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sunshine@sunshineco.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.