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 <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
