Depending on what you're doing, you could go with proto_tree_add_xxx_format_value. I think that's how most dissectors end up avoiding the need for BASE_CUSTOM callback. -----Original Message----- From: Thomas Wiens <[email protected]> To: Developer support list for Wireshark <[email protected]> Sent: Fri, Oct 21, 2016 4:45 pm Subject: Re: [Wireshark-dev] Problem with val_to_str inside BASE_CUSTOM callback function
On 21.10.2016 22:17, Guy Harris wrote: > On Oct 21, 2016, at 1:08 PM, Jaap Keuter <[email protected]> wrote: > >> For my understanding, would this be covered by using >> val_to_str_wmem(wmem_file_scope(), val, vs, fmt); > > Yes, but the strings will remain allocated until the capture file is closed, > even if that's not necessary. I think that I will use val_to_str_const instead, because I'm using more than one val_to_str inside my callback function. I already have problems with high memory usage, because in the protocol I'm working on, I have to reassemble a possible huge number of packets before dissecting them. Maybe I have to ask some of you experts in a separate thread, of how to deal with this. Maybe there are also other protocols which have the same issues. It seems that no other dissector is using val_to_str inside the callback. But I think that problem would occur at least with a fuzz test. -- Thomas ___________________________________________________________________________ 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
___________________________________________________________________________ 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
