Hi, On 2019-10-04 17:08:29 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2019-10-04 16:31:29 -0400, Bruce Momjian wrote: > >> Yeah, it is certainly weird that you have to assign the first array > >> element to get the rest to be zeros. By using a macro, we can document > >> this behavior in one place. > > > IDK, to me this seems like something one just has to learn about C, with > > the macro just obfuscating that already required knowledge. It's not > > like this only applies to stack variables initializes with {0}. It's > > also true of global variables, or function-local static ones, for > > example. > > Huh? For both those cases, the *default* behavior, going back to K&R C, > is that the variable initializes to all-bits-zero. There's no need to > write anything extra.
What I mean is that if there's any initialization, it's to all zeroes, except for the parts explicitly initialized explicitly. And all that the {0} does, is that the rest of the fields are initialized the way other such initialization happens. There's plenty places where we don't initialize every part, e.g. a struct member, of global variables (and for stack allocated data as well, increasingly so). To be able to make sense of things like somevar = {.foo = bar /* field blub is not initialized */}; or things like guc.c - where we rely on zero initialize most fields of config_generic. > If some people are writing {0} there, I think > we should discourage that on the grounds that it results in inconsistent > coding style. Yea, I'm not advocating that. Greetings, Andres Freund