MIME-Version: 1.0
References: <CAEudQArzX-q7FuvHxcEQKP9RuM7eFw4CnvU_xQtkiu4+tnaA4A@mail.gmail.com>
 <CABwTF4W+WMr=3bjLP5-69+oG81BEZOH+SAqPX8GDnZry5==thA@mail.gmail.com>
 <ZIgIjhYW81WCTYc4@paquier.xyz> <20230613.163921.1246444645573084901.horikyota.ntt@gmail.com>
 <CAMbWs48ihqQKK=6vBrL75fQoAv8dc3ahJBGyyiDz3YDFAxbTuA@mail.gmail.com>
 <CAEudQAr7araiFMW5CN3U3nb72DmoQxQ8-VYh2x0W_3EwKBbefg@mail.gmail.com>
 <CABwTF4UkJzNkDsYfECt-zEZd6eUtzUG0WyngtMAReQEsBwCeGQ@mail.gmail.com>
 <CAEudQAqyBzH-nnhwkPsMzP8TGMR164XDO5fdk+b5-XKp2KuxrQ@mail.gmail.com>
 <CACiT8iZwaLuomnM2Jo9mO5bSWU4XGdBdACsm4tMU3XybuBOxSg@mail.gmail.com>
 <CAEudQAr78B8eme9rfzJsT__UOqBWW42csFwUM9ynuzhnCBceOw@mail.gmail.com> <CACiT8iZC3NswchmNipaZN0o7_15e1zQyYONdqBSON1p-gE2-ew@mail.gmail.com>
In-Reply-To: <CACiT8iZC3NswchmNipaZN0o7_15e1zQyYONdqBSON1p-gE2-ew@mail.gmail.com>
From: Gurjeet Singh <gurjeet@singh.im>
Date: Thu, 6 Jul 2023 12:06:20 -0700
Message-ID: <CABwTF4WO7jo6xRX9z1LO5Ktpr6NwNxDCXorJX3AURBceELLkbw@mail.gmail.com>
Subject: Re: Avoid unncessary always true test (src/backend/storage/buffer/bufmgr.c)
To: Karina Litskevich <litskevichkarina@gmail.com>
Cc: Ranier Vilela <ranier.vf@gmail.com>, Richard Guo <guofenglinux@gmail.com>, 
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>, michael@paquier.xyz, pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CABwTF4WO7jo6xRX9z1LO5Ktpr6NwNxDCXorJX3AURBceELLkbw%40mail.gmail.com>
Precedence: bulk

On Thu, Jul 6, 2023 at 8:01=E2=80=AFAM Karina Litskevich
<litskevichkarina@gmail.com> wrote:
>
>
>> EB_SMGR and EB_REL are macros for making new structs.
>> IMO these are buggy, once make new structs without initializing all fiel=
ds.
>> Attached a patch to fix this and make more clear when rel or smgr is NUL=
L.
>
>
> As long as a structure is initialized, its fields that are not present in
> initialization are initialized to zeros and NULLs depending on their type=
s.
> See C99 Standard 6.7.8.21 and 6.7.8.10. This behaviour is quite well know=
n,
> so I don't think this place is buggy. Anyway, if someone else says the co=
de
> is more readable with these fields initialized explicitly, then go on.

Even though I am not a fan of the Designated Initializers feature, I
agree with Karina. Per the standard, the unmentioned fields get
initialized to zeroes/NULLs, so the explicit initialization to
zero/null that this additional patch does is unnecessary. Moreover, I
feel that it makes the code less pleasant to read.

C99, 6.7.8.21:
> If there are fewer initializers in a brace-enclosed list than there are
> elements or members of an aggregate, or fewer characters in a string lite=
ral
> used to initialize an array of known size than there are elements in the =
array,
> the remainder of the aggregate shall be initialized implicitly the same a=
s
> objects that have static storage duration.

C99, 6.7.8.10:
> If an object that has automatic storage duration is not initialized expli=
citly,
> its value is indeterminate. If an object that has static storage duration=
 is
> not initialized explicitly, then:
> - if it has pointer type, it is initialized to a null pointer;
> - if it has arithmetic type, it is initialized to (positive or unsigned) =
zero;
> - if it is an aggregate, every member is initialized (recursively) accord=
ing to these rules;
> - if it is a union, the first named member is initialized (recursively) a=
ccording to these rules.


Best regards,
Gurjeet
http://Gurje.et