Wireshark mailing list archives
Philosophy question - avoiding g_alloc in dissectors?
From: Craig Jackson <cejackson51 () gmail com>
Date: Tue, 30 Jan 2018 13:02:58 -0500
I have a place in my dissector where g_strjoin would fit my needs exactly, and make clean code. However, it calls g_alloc, which I am assuming is heavier than the allocator used for wmem_packet_scope. I see there's a wmem_strconcat, but that doesn't quite fit my needs. It could but not as well. The string isn't long (ITEM_LABEL_LENGTH max) and has up to three components, so I could also write open code to put things into a buffer allocated on the stack. They would then be copied into a wmem_packet_scope allocated buffer. I see three alternatives. Which is preferred? 1. Write my open code, finishing with wmem_strdup(). 2. Use g_strjoin(), and then wmem_strdup the result. 3. Add a wmem_strjoin to wmem/wmem_strutl.[ch], modeled after wmem_strconcat and g_strjoin. I notice that g_strjoin is only used in dissectors/packet-rtps.c, and this suggests to me that option (2) is to be avoided. Many of the other places I see g_alloc/g_free used in dissectors have to do with things like uats which are long-lived structures. I'm thinking that (3) is the best, but I want confirmation from the more experienced developers. Also, if I create wmwm_strjoin, should I fix packet-rtps.c? I would have to way to test it unless there is an archive of rtps captures. Craig Jackson
___________________________________________________________________________ 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
Current thread:
- Philosophy question - avoiding g_alloc in dissectors? Craig Jackson (Jan 30)
- Re: Philosophy question - avoiding g_alloc in dissectors? Dario Lombardo (Jan 31)