Re: [PATCH 3/5] reftable/stack: fix compiler warning due to missing braces

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxx> 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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux