netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phil Sutter <phil@nwl.cc>
To: Eric Leblond <eric@regit.org>
Cc: pablo@netfilter.org, netfilter-devel@vger.kernel.org
Subject: Re: [nft PATH 10/16] libnftables: get rid of printf
Date: Thu, 17 Aug 2017 12:01:11 +0200	[thread overview]
Message-ID: <20170817100111.GX16375@orbyte.nwl.cc> (raw)
In-Reply-To: <20170816204310.3371-11-eric@regit.org>

On Wed, Aug 16, 2017 at 10:43:04PM +0200, Eric Leblond wrote:
[...]
> diff --git a/include/nftables.h b/include/nftables.h
> index 348fbb0..ddff5d8 100644
> --- a/include/nftables.h
> +++ b/include/nftables.h
> @@ -30,6 +30,8 @@ struct output_ctx {
>  	unsigned int ip2name;
>  	unsigned int handle;
>  	unsigned int echo;
> +	void *ctx;
> +	int (*print)(void *ctx, const char *format, ...);
>  };

My compiler says:

| libnftables.c: In function 'nft_context_new':
| libnftables.c:113:20: warning: assignment left-hand side might be a candidate for a format attribute [-Wsuggest-attribute=format]
|   ctx->output.print = nft_print;
|                     ^

Not really a warning IMO, though.

Abstracting the topic a bit, maybe all these foo_print() callbacks
should die eventually and be replaced by formatters for different output
types, similar to nftnl_foo_snprintf() functions. Maybe the whole output
formatting actually even belongs to the application and libnftables has
to provide a way to extract object information. Not sure how much
knowlege the application should (need to) have about internal data
structures like e.g., struct table or struct expr.

Cheers, Phil

  reply	other threads:[~2017-08-17 10:01 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-16 20:42 [nft PATCH 0/16] introduce libnftables Eric Leblond
2017-08-16 20:42 ` [nft PATH 01/16] libnftables: introduce library Eric Leblond
2017-08-17  8:57   ` Phil Sutter
2017-08-17 17:09     ` Eric Leblond
2017-08-17 17:13       ` Phil Sutter
2017-08-19  8:43         ` Eric Leblond
2017-08-19 19:07           ` Jan Engelhardt
2017-08-21  8:19             ` Pablo Neira Ayuso
2017-08-16 20:42 ` [nft PATH 02/16] libnftables: add context new and free Eric Leblond
2017-08-17  9:04   ` Phil Sutter
2017-08-16 20:42 ` [nft PATH 03/16] libnftables: add nft_run_command_from_buffer Eric Leblond
2017-08-17  9:21   ` Phil Sutter
2017-08-16 20:42 ` [nft PATH 04/16] libnftables: add nft_run_command_from_filename Eric Leblond
2017-08-16 20:42 ` [nft PATH 05/16] libnftables: put nft_run in library Eric Leblond
2017-08-16 20:43 ` [nft PATH 06/16] libnftables: add missing variable to library Eric Leblond
2017-08-17  9:35   ` Phil Sutter
2017-08-19 11:02     ` Eric Leblond
2017-08-16 20:43 ` [nft PATH 07/16] libnftables: add NFT_EXIT_* " Eric Leblond
2017-08-16 20:43 ` [nft PATH 08/16] libnftables: add a nft_cache to nft_ctx Eric Leblond
2017-08-17  9:43   ` Phil Sutter
2017-08-16 20:43 ` [nft PATH 09/16] libnftables: move iface_cache_release to deinit Eric Leblond
2017-08-16 20:43 ` [nft PATH 10/16] libnftables: get rid of printf Eric Leblond
2017-08-17 10:01   ` Phil Sutter [this message]
2017-08-19  8:59     ` Eric Leblond
2017-08-16 20:43 ` [nft PATH 11/16] libnftables: add nft_context_set_print Eric Leblond
2017-08-16 20:43 ` [nft PATH 12/16] libnftables: transaction support Eric Leblond
2017-08-17 10:11   ` Phil Sutter
2017-08-16 20:43 ` [nft PATH 13/16] libnftables: set max_errors to 1 in library Eric Leblond
2017-08-16 20:43 ` [nft PATH 14/16] erec: add function to free list Eric Leblond
2017-08-16 20:43 ` [nft PATH 15/16] libnftables: add error handling Eric Leblond
2017-08-17 10:32   ` Phil Sutter
2017-08-19  9:04     ` Eric Leblond
2017-08-16 20:43 ` [nft PATH 16/16] libnftables: basic doxygen documentation Eric Leblond
2017-08-17  8:32 ` [nft PATCH 0/16] introduce libnftables Arturo Borrero Gonzalez
2017-08-17  8:58   ` Eric Leblond
2017-08-17 10:35     ` Florian Westphal
2017-08-17 10:47   ` Phil Sutter

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=20170817100111.GX16375@orbyte.nwl.cc \
    --to=phil@nwl.cc \
    --cc=eric@regit.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).