On Fri, Mar 16, 2018 at 06:45:57PM +0100, Jakub Zawadzki wrote:
> > > W dniu 2018-03-15 13:24, Peter Wu napisał(a):
> > > > I was looking at memleaks as reported by LSAN while running the
> > > > decryption test suite, there are quite a number of occurrences.
> > >
> > > Can register_tap_listener() return enum code (one of: success, not
> > > found, wrong filter)? You will get rid of memleak, and users will
> > > get nicely translated message error.
> >
> > That sounds like a great idea at first, but it seems not viable given
> > that the error messages are:
> >
> > - "Tap <tapname parameter> not found"
>
> <tapname parameter> is passed by caller, so caller should be able to show it
> in message error.
>
> > - "Filter "<fstring parameter>" is invalid - <dfilter_compile error>"
>
> Ah, I only did notice <fstring parameter> which is also passed by caller,
> didn't notice dfilter_compile_error thing :(
>
> Would it be to big change to pass compiled dfilter to
> register_tap_listener()?
Many callers pass NULL a dfilter, but not all of them do. If callers
become responsible for compiling the dfilter, then they would also have
to handle errors in register_tap_listener. For simplicity of the
interface, I think it is better to keep the filter string argument.
So, returning a string (char *) it is?
--
Kind regards,
Peter Wu
https://lekensteyn.nl
