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

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-17 05:37:11
Message-ID: CA+hUKG+PTbLPF5KsLoaoV5ZO7_SMFNZ9p4uHuWVuujGUE-vTiQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 8, 2019 at 11:09 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Sat, Oct 5, 2019 at 3:10 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2019-10-04 17:08:29 -0400, Tom Lane wrote:
> > > 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.
> >
> > 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.
> >
>
> You have a point and I think over time everyone will know this.
> However, so many people advocating for having a macro with a comment
> to be more explicit about this behavior shows that this is not equally
> obvious to everyone or at least they think that it will help future
> patch authors.
>
> Now, I think as the usage ({0}) already exists in the code, so I think
> if we decide to use a macro, then ideally those places should also be
> changed. I am not telling that it must be done in the same patch, we
> can even do it as a separate patch.
>
> I am personally still in the camp of people advocating the use of
> macro for this purpose. It is quite possible after reading your
> points, some people might change their opinion or some others also
> share their opinion against using a macro in which case we can drop
> the idea of using a macro.

-1 for these macros.

These are basic facts about the C language. I hope C eventually
supports {} like C++, so that you don't have to think hard about
whether the first member is another struct, and recursively so … but
since the macros can't help with that problem, what is the point?

I am reminded of an (apocryphal?) complaint from an old C FAQ about
people using #define BEGIN {.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mahendra Singh 2019-10-17 06:17:58 Re: [HACKERS] Block level parallel vacuum
Previous Message Michael Paquier 2019-10-17 05:35:13 Re: recovery_min_apply_delay in archive recovery causes assertion failure in latch