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
-
Replace many MemSet calls with struct initialization
- 9fd45870c143 16.0 landed
-
Change some unnecessary MemSet calls
- 258f48f858b0 16.0 landed
-
Avoid unnecessary MemSet call
- 8cd61d288adf 16.0 landed