Re: register_tap_listener memleak

[Peter Wu <peter () lekensteyn nl>]

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
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe