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

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)
Date: 2022-05-18 00:08:59
Message-ID: CAEudQAphdTfepoaoEVjxAhBVyRcdVRQ-m1CTCSr2bbBaOgRWEA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em ter., 17 de mai. de 2022 às 20:18, Justin Pryzby <pryzby(at)telsasoft(dot)com>
escreveu:

> On Tue, May 17, 2022 at 07:52:30PM -0300, Ranier Vilela wrote:
> > I found, I believe, a serious problem of incorrect usage of the memset
> api.
> > Historically, people have relied on using memset or MemSet, using the
> > variable name as an argument for the sizeof.
> > While it works correctly, for arrays, when it comes to pointers to
> > structures, things go awry.
>
> Knowing how sizeof() works is required before using it - the same is true
> for
> pointers.
>
> > So throughout the code there are these misuses.
>
> Why do you think it's a misuse ?
>
> Take the first one as an example. It says:
>
> GenericCosts costs;
> MemSet(&costs, 0, sizeof(costs));
>
> You sent a patch to change it to sizeof(GenericCosts).
>
> But it's not a pointer, so they are the same.
>
> Is that true for every change in your patch ?
>
It seems true, sorry.
Thanks Justin for pointing out my big mistake.

I hope this isn't all wasted work, but should I remove the 002 patch.

regards,
Ranier Vilela

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Soumyadeep Chakraborty 2022-05-18 00:10:27 ALTER TABLE SET ACCESS METHOD on partitioned tables
Previous Message Tom Lane 2022-05-17 23:22:20 Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)