Wireshark-bugs: [Wireshark-bugs] [Bug 8089] New Dissector - SEL (Schweitzer Engineering Laborato
Comment # 16
on bug 8089
from Chris Bontje
(In reply to comment #15)
> No, wmem should not be used with other glib memory functions, as wmem memory
> is not necessarily allocated via glib. The reason it continues to work is
> that you're never actually using it - you allocate wmem memory correctly and
> then immediately (on the very next line) reassign that variable to the
> result of fmconfig_frame_fast, whose memory comes from glib still.
>
> I expect most of the wmem work will be in fmconfig_frame_fast - all the
> calls to g_slice_new and g_array_* in that function should be replaced with
> similar or equivalent wmem calls. If wmem doesn't provide an exact
> equivalent it should be pretty easy to mimic with regular wmem_alloc()
> calls, or I can take a stab at adding to the wmem arsenal.
>
I'm not seeing a whole lot of wmem examples through-out the source right now,
and the ones that are there (IP and smtp) seem to use a struct of hard-coded
size, without dynamically associated arrays.
What would be the wmem equivalent of g_array_append_val? The issue I can see
right now is that at the beginning of running config_frame_fast, I know I of
course have a configuration frame. Within that configuration frame, there will
be one cfg_data struct that has a variable length number of ai_info structs.
Am I right in thinking that the existing wmem_alloc calls are good for
assigning a new chunk of memory, not-so-good at appending an existing one?
I see there are some calls called "stacks" and "slabs" that could be referenced
in the wmem libraries, not sure if these are stacks I can dump data into and
then pull out of when required?
Ideally at the end of the day, what the selfm dissector needs is way to
store/retrieve a conversation with this structure:
- struct with pointers on any encountered config frames
- within the pointer to fast meter A5C1/C2/C3 frame, associated cfg_data and
dynamic ai information.
A A5D1, A5D2 or A5D3 frame needs to refer back to it's corresponding "C" frame,
so if there's a way in the new memory management library to do that, I'm all
ears.
Chris
You are receiving this mail because:
- You are watching all bug changes.
