Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Ranier Vilela <ranier.vf@gmail.com>

From: Ranier Vilela <ranier.vf@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, David Zhang <david.zhang@highgo.ca>, Justin Pryzby <pryzby@telsasoft.com>, David Rowley <dgrowleyml@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2022-08-24T19:49:59Z
Lists: pgsql-hackers
Em qua., 24 de ago. de 2022 às 16:41, Robert Haas <robertmhaas@gmail.com>
escreveu:

> On Wed, Aug 24, 2022 at 3:20 PM Ranier Vilela <ranier.vf@gmail.com> wrote:
> > But, these same arguments apply to Designated Initializers [1].
> >
> > like:
> > struct foo a = {
> >    .i = 0,
> >    .b = 0,
> > };
> >
> > That is slowly being introduced and IMHO brings the same problems with
> padding bits.
>
> Yep. I don't find that an improvement over a MemSet on the struct
> either, if we're just using it to fill in zeroes.
>
> If we're using it to fill in non-zero values, though, then there's a
> reasonable argument that it offers some notational convenience.
>
Even in that case, it still hides bugs.
All arguments against {0} apply entirely to this initialization type.
Because the padding bits remain uninitialized.

Note that where all major compilers are correctly initializing padding bits
with {0}, then this misbehavior will become of no practical effect in the
future.

regards,
Ranier Vilela

Commits

  1. Replace many MemSet calls with struct initialization

  2. Change some unnecessary MemSet calls

  3. Avoid unnecessary MemSet call