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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Chapman Flack <chap(at)anastigmatix(dot)net>, Ashwin Agrawal <aagrawal(at)pivotal(dot)io>, Jacob Champion <pchampion(at)pivotal(dot)io>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Make use of C99 designated initialisers for nulls/values arrays
Date: 2019-10-04 21:08:29
Message-ID: 23845.1570223309@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)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. If some people are writing {0} there, I think
we should discourage that on the grounds that it results in inconsistent
coding style.

Note that I'm not proposing a rule against, say,

static MyNodeType *my_variable = NULL;

That's perfectly sensible and adds no cognitive load that I can see.
But in cases where you have to indulge in type punning or reliance on
obscure language features to get the result that would happen if you'd
just not written anything, I think you should just not write anything.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2019-10-04 21:31:00 Re: Transparent Data Encryption (TDE) and encrypted files
Previous Message Bruce Momjian 2019-10-04 20:58:14 Re: Transparent Data Encryption (TDE) and encrypted files