Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: [Wireshark-dev] Philosophy question - avoiding g_alloc in dissectors?

From: Craig Jackson <cejackson51@xxxxxxxxx>
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