All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Sutter <phil@nwl.cc>
To: Pablo Neira Ayuso <pablo@netfilter.org>
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:49:58 +0200	[thread overview]
Message-ID: <ZQsitnx/cPf2cPk0@orbyte.nwl.cc> (raw)
In-Reply-To: <ZQsYf3moTtXQytXX@calendula>

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).

Cheers, Phil

  reply	other threads:[~2023-09-20 16:50 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 [this message]
2023-09-20 16:52         ` Pablo Neira Ayuso
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=ZQsitnx/cPf2cPk0@orbyte.nwl.cc \
    --to=phil@nwl.cc \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --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.