Re: Proposal: Make use of C99 designated initialisers fornulls/values arrays

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