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