Hi,
On Thu, 2017-08-17 at 12:01 +0200, Phil Sutter wrote:
> 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.
Agree, this was a first approach. Not sending structured data is
problem in a modern library.
We have already dumping of object in JSON or XML. It maybe could be
used as communication method to send structured data to the user
applications. Don't know if it is a lazy way but maybe it could be
enough.
++
--
Eric Leblond <eric@xxxxxxxxx>
Blog: https://home.regit.org/
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
