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 }
So I am not sure how the advice in the new comment really helps the
intended audiences. Shouldn't the advice be more like
NOTE: when a structure foo has FOO_INIT macro to initialize,
*never* use your own initialization like so:
struct foo foo_instance = { .member_i_care_about = 13 };
Instead, use the _INIT macro and then assign to the member you
care about, like so:
struct foo foo_instance = FOO_INIT;
foo_instance.member_i_care_about = 13;
This is because there may be members of "struct foo" whose
default value is not zero, or there will later be added such
members to the structure.
perhaps?
I can buy a counter-proposal that does not forbid a custom
designated initializers that depends on "all zero" default IF it
gives a piece of advice to the readers that is more usable than
"consider strongly before adding", as "consider strongly before
adding" there smells like just an euphemism for "never add", though.
Thanks.
