From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Phil Sutter <phil@nwl.cc>, Thomas Haller <thaller@redhat.com>,
NetFilter <netfilter-devel@vger.kernel.org>
Subject: Re: [PATCH nft 3/4] all: add free_const() and use it instead of xfree()
Date: Wed, 20 Sep 2023 18:52:54 +0200 [thread overview]
Message-ID: <ZQsjZnV63YTQc9kk@calendula> (raw)
In-Reply-To: <ZQsitnx/cPf2cPk0@orbyte.nwl.cc>
On Wed, Sep 20, 2023 at 06:49:58PM +0200, Phil Sutter wrote:
> On Wed, Sep 20, 2023 at 06:06:23PM +0200, Pablo Neira Ayuso wrote:
> > On Wed, Sep 20, 2023 at 04:13:43PM +0200, Phil Sutter wrote:
> > > On Wed, Sep 20, 2023 at 03:13:40PM +0200, Thomas Haller wrote:
> > > [...]
> > > > There are many places that rightly cast away const during free. But not
> > > > all of them. Add a free_const() macro, which is like free(), but accepts
> > > > const pointers. We should always make an intentional choice whether to
> > > > use free() or free_const(). Having a free_const() macro makes this very
> > > > common choice clearer, instead of adding a (void*) cast at many places.
> > >
> > > I wonder whether pointers to allocated data should be const in the first
> > > place. Maybe I miss the point here? Looking at flow offload statement
> > > for instance, should 'table_name' not be 'char *' instead of using this
> > > free_const() to free it?
> >
> > The const here tells us that this string is set once and it gets never
> > updated again, which provides useful information when reading the
> > code IMO.
>
> That seems like reasonable rationale. I like to declare function
> arguments as const too in order to mark them as not being altered by the
> function.
>
> With strings, I find it odd to do:
>
> const char *buf = strdup("foo");
> free((void *)buf);
>
> > I interpret from Phil's words that it would be better to consolidate
> > this to have one single free call, in that direction, I agree.
>
> No, I was just wondering why we have this need for free_const() in the
> first place (i.e., why we declare pointers as const if we allocate/free
> them).
>
> > /* Just free(), but casts to a (void*). This is for places where
> > * we have a const pointer that we know we want to free. We could just
> > * do the (void*) cast, but free_const() makes it clear that this is
> > * something we frequently need to do and it's intentional. */
> > #define free_const(ptr) free((void *)(ptr))
> >
> > I like this macro.
> >
> > Maybe turn it into:
> >
> > nft_free(ptr)
> >
> > and we use it everywhere?
>
> I believe this is exactly what Thomas is trying to move away from. IIUC,
> he wants to have a "special" free() to mark the spots where a const
> pointer is freed (and make it a more deliberate action).
OK.
Then we can follow Thomas' approach, it might also help review other
existing free() calls, it might be possible to move some of them to
use free_const() because maybe some of these fields should be using
const in the structure definition.
next prev parent reply other threads:[~2023-09-20 16:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-20 13:13 [PATCH nft 0/4] remove xfree() and add free_const()+nft_gmp_free() Thomas Haller
2023-09-20 13:13 ` [PATCH nft 1/4] datatype: don't return a const string from cgroupv2_get_path() Thomas Haller
2023-09-20 13:13 ` [PATCH nft 2/4] gmputil: add nft_gmp_free() to free strings from mpz_get_str() Thomas Haller
2023-09-20 14:05 ` Phil Sutter
2023-09-20 14:46 ` Thomas Haller
2023-09-20 16:04 ` Phil Sutter
2023-09-20 13:13 ` [PATCH nft 3/4] all: add free_const() and use it instead of xfree() Thomas Haller
2023-09-20 14:13 ` Phil Sutter
2023-09-20 16:06 ` Pablo Neira Ayuso
2023-09-20 16:49 ` Phil Sutter
2023-09-20 16:52 ` Pablo Neira Ayuso [this message]
2023-09-20 18:03 ` Thomas Haller
2023-09-20 18:22 ` Phil Sutter
2023-09-20 19:48 ` Thomas Haller
2023-09-20 22:50 ` Phil Sutter
2023-09-21 9:08 ` Thomas Haller
2023-09-20 13:13 ` [PATCH nft 4/4] all: remove xfree() and use plain free() Thomas Haller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZQsjZnV63YTQc9kk@calendula \
--to=pablo@netfilter.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=phil@nwl.cc \
--cc=thaller@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.