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-requ...@wireshark.org?subject=unsubscribe
