From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Steele <david(at)pgmasters(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Use C99 designated initializers for some structs |
Date: | 2018-08-30 04:57:36 |
Message-ID: | 20180830045736.p3mrugcq2j367a3l@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-08-29 18:51:24 -0400, Tom Lane wrote:
> I agree that assuming that they're physically zeroes is OK from a
> portability standpoint, because we'd have a whole lot of other issues
> if they weren't. But I have a different point to make, which is that
> it's fairly standard practice for us to initialize all fields of a struct
> explicitly, even when setting them to zero/false/NULL. I don't think we
> should walk away from that practice just because C99 offers a shiny new
> syntax for doing so.
>
> The main practical advantage I see to writing such "redundant" explicit
> field initializations is that it aids greppability: when you're adding a
> new field Y beside field X, grepping for X is a good way of finding the
> places where you need to initialize/copy/write/read/generically-frob Y
> too. Omitting mention of X just because you're implicitly initializing
> it puts a big hole in the reliability of that technique.
FWIW, I think this has for bigger costs than gains. You can't rely on
it being done everywhere anyway - there's *heaps* of places were we
don't set all members - and it makes changing fieldnames etc. way more
verbose than it has to be.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2018-08-30 05:42:09 | Re: A strange GiST error message or fillfactor of GiST build |
Previous Message | Andres Freund | 2018-08-30 04:55:31 | Re: Use C99 designated initializers for some structs |