Re: [PATCH v2 2/8] object-store-ll.h: add note about designated initializers
- From
Taylor Blau <me@ttaylorr.com>
- Date
- Apr 15, 2025, 19:51 UTC
- Message-ID
- <Z/64prrBW77QSznZ@nand.local>
- In-Reply-To
- <xmqqsemapi40.fsf@gitster.g>
On Mon, Apr 14, 2025 at 02:07:27PM -0700, Junio C Hamano wrote:
Show 28 quoted lines
> Taylor Blau <me@ttaylorr.com> writes:
>
> > @@ -337,6 +337,14 @@ struct object_info {
> > /*
> > * Initializer for a "struct object_info" that wants no items. You may
> > * also memset() the memory to all-zeroes.
> > + *
> > + * NOTE: callers expect the initial value of an object_info struct to
> > + * be zero'd out. Designated initializers like
> > + *
> > + * struct object_info oi = { .sizep = &sz };
> > + *
> > + * depend on this behavior, so consider strongly before adding new
> > + * fields that have a non-zero default value.
> > */
> > #define OBJECT_INFO_INIT { 0 }
>
> Hmph, after thinking hard enough, if a developer cannot come up with
> a way to avoid non-zero default value, the callers could just work
> if they instead did
>
> struct object_info oi = OBJECT_INFO_INIT;
> oi.sizep = &sz;
>
> and the member of non-zero default value can be delat with by
> updating the default initializer, perhaps like
>
> #define OBJECT_INFO_INIT { .enabled = 1 }Yeah... that's what I was trying to get at with this patch. Basically, "if you have an _INIT macro with non-zero defaults, don't use a custom designated initializer and instead assign fields after using the _INIT macro (which itself is a designated initializer)".
But like I wrote to Elijah in the same sub-thread, I think that there is probably more to discuss here, so I ejected this patch from my copy of the series and will re-submit it as its own series later on.
Thanks, Taylor