Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)
От | Ranier Vilela |
---|---|
Тема | Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c) |
Дата | |
Msg-id | CAEudQAqeHCRDFpkJht4DV5vCQbU--YfEb3CiG-TyyVJ1Tjn9Uw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c) (Robert Haas <robertmhaas@gmail.com>) |
Список | 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.
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.
with {0}, then this misbehavior will become of no practical effect in the future.
regards,
Ranier Vilela
В списке pgsql-hackers по дате отправления: