Re: [PATH nft v2 13/18] libnftables: add nft_context_set_print

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Wed, Aug 30, 2017 at 12:46:17PM +0200, Pablo Neira Ayuso wrote:
> On Fri, Aug 25, 2017 at 01:49:56PM +0200, Eric Leblond wrote:
> > On Fri, 2017-08-25 at 11:59 +0200, Pablo Neira Ayuso wrote:
> > > On Sat, Aug 19, 2017 at 05:24:15PM +0200, Eric Leblond wrote:
> > > > diff --git a/src/libnftables.c b/src/libnftables.c
> > > > index 7209885..f0decae 100644
> > > > --- a/src/libnftables.c
> > > > +++ b/src/libnftables.c
> > > > @@ -86,6 +86,15 @@ struct nft_ctx *nft_context_new(void)
> > > >  	return ctx;
> > > >  }
> > > >  
> > > > +void nft_context_set_print_func(struct nft_ctx *nft,
> > > > +				int (*print)(void *ctx, const char
> > > > *fmt, ...),
> > > > +				void *ctx)
> > > 
> > > Can we have a strict type here instead of void *ctx? I mean, if ctx
> > > is
> > > always going to be a file descriptor, I would prefer this is a
> > > specific type.
> > > 
> > > Or are you envisioning any real use of this generic type? If we
> > > cannot
> > > forecast anything reasonable, then a strict type is the way to go
> > > IMO.
> > 
> > Yes, it can be any internal structure from the user application. For
> > instance, it can be a structure storing logging information, that
> > accumulate the buffer and do a line by line output in a GUI.
> 
> I don't think we can do snprintf() with this interface, or any other
> printing to buffer with this approach.
> 
> We would need to update the libnftables codebase to keep track of
> offsets and so on.

Forget this. We can indeed use this API to implement buffer like
printing.

But I would prefer strict typing for this API, so we provide to
functions, one to print to buffer and another to print to descriptors,
if this is what you need.

Otherwise, just provide a function that does exactly what you need
right now, with strict typing. If someone else needs a new function to
do something else, then let's wait for them to come and ask for it.

OK?