On Mon, Apr 14, 2025 at 02:07:27PM -0700, Junio C Hamano wrote:
> Taylor Blau <me@xxxxxxxxxxxx> 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
