On 10/2/19 8:46 AM, Tom Lane wrote:
> Joe Nelson <joe@begriffs.com> writes:
>> Isaac Morland wrote:
>>> I hope you'll forgive a noob question. Why does the "After"
>>> initialization for the boolean array have {0} rather than {false}?
>
>> I think using a value other than {0} potentially gives the incorrect
>> impression that the value is used for *all* elements of the
>> array/structure, whereas it is only used for the first element.
>
> There's been something vaguely bothering me about this proposal,
> and I think you just crystallized it.
>
>> Using {false} may encourage the unwary to try
>> bool foo[2] = {true};
>> which will not set all elements to true.
>
> Right. I think that in general it's bad practice for an initializer
> to not specify all fields/elements of the target. It is okay in the
> specific case that we're substituting for a memset(..., 0, ...).
> Perhaps we could make this explicit by using a coding style like
>
> /* in c.h or some such place: */
> #define INIT_ALL_ZEROES {0}
>
> /* in code: */
> Datum values[N] = INIT_ALL_ZEROES;
>
> and then decreeing that it's not project style to use a partial
> initializer other than in this way.
There are numerous locations in the code that raise warnings when
-Wmissing-field-initializers is handed to gcc. See, for example,
src/backend/utils/adt/formatting.c where
static const KeyWord NUM_keywords[]
is initialized, and the code comment above that disclaims the need to
initialize is_digit and date_mode. Are you proposing cleaning up all
such incomplete initializations within the project?
I understand that your INIT_ALL_ZEROS macro does nothing to change
whether -Wmissing-field-initializers would raise a warning. I'm
just asking about the decree you propose, and I used that warning flag
to get the compiler to spit out relevant examples.
mark
