All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Thomas Haller <thaller@redhat.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
	NetFilter <netfilter-devel@vger.kernel.org>
Subject: Re: [PATCH nft 1/2] utils: add memory_allocation_check() helper
Date: Wed, 15 Nov 2023 09:52:48 +0100	[thread overview]
Message-ID: <20231115085248.GD14621@breakpoint.cc> (raw)
In-Reply-To: <2c3a28999adc1fa22b9b822bdae5ab79817957fa.camel@redhat.com>

Thomas Haller <thaller@redhat.com> wrote:
> static inline void *__memory_allocation_check(const char *file, unsigned line, const void *ptr) {
>     if (!ptr)
>         __memory_allocation_error(file, line);
>     return (void*) ptr;
> }
> 
> #define memory_allocation_check(cmd) \
>    ((typeof(cmd) __memory_allocation_check(__FILE__, __LINE__, (cmd))
> 
> Doesn't seem to make a difference either way.

We seem to be moving in circles.

I suspect your agenda is to avoid repeating the existing

x = alloc()
if (!x)
  barf()

pattern when adding userhandle support?

If so I think its best to just add a specific ubuf alloc wrapper that
can't fail (i.e. like the 'xmalloc' wrappers).

Like Pablo said, I don't see any added value in providing FILE/LINE
errors on stderr here.  It could be as simple as exit().


  reply	other threads:[~2023-11-15  8:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-08 18:24 [PATCH nft 1/2] utils: add memory_allocation_check() helper Thomas Haller
2023-11-08 18:24 ` [PATCH nft 2/2] netlink: add and use _nftnl_udata_buf_alloc() helper Thomas Haller
2023-11-09 15:14   ` Pablo Neira Ayuso
2023-11-09 15:19     ` Thomas Haller
2023-11-09 15:32       ` Pablo Neira Ayuso
2023-11-09 16:48         ` Thomas Haller
2023-11-09 19:12           ` Pablo Neira Ayuso
2023-11-09 15:24 ` [PATCH nft 1/2] utils: add memory_allocation_check() helper Pablo Neira Ayuso
2023-11-09 17:02   ` Thomas Haller
2023-11-15  8:52     ` Florian Westphal [this message]
2023-11-15  9:06       ` 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=20231115085248.GD14621@breakpoint.cc \
    --to=fw@strlen.de \
    --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.