Comment # 8
on bug 9607
from Michael Mann
(In reply to comment #7)
Thoughts
> on a couple of the linking problems:
- mtp3_pc_to_str_buf is not used
> outside of packet-mtp3.c that I can see. Just make it static-local to that
> file or is it used in third-party plugins?
it's used in address_to_str functions which is why it's an issue. Still not
sure fileshark would need address_to_str functions, but that's the "fun" in
carving up epan.
- frame end-routines are only
> called as the very last things in dissect_frame; it is probably simplest to
> move that calling code into dissect_packet (packet.c) instead, immediately
> after call_dissector(frame_handle, ...), since file dissection code could
> theoretically want to register end-of-file dissection routines as well
I like the suggestion.
-
> any code that is really truly protocol-specific (eg gcp.c) should live with
> that protocol proper
Agreed. There seems to be a good chunk of "dissector specific" code in epan
that has the philosophy of "it's used by multiple dissectors, abstract to
epan", rather than just put it in a dissector and have the other dissector(s)
reference a dissector header file.
- the hf refs in print.c are tricky; PDML is a
> packet-specific markup language, so I'm not sure it makes sense to even have
> that available for tfshark...
I liked Jakub's suggestion of moving it to /ui, but I'm not sure if it will
needed to be carved up/abstracted more to support fileshark not having
dissector source.
My current progress is trying to create a filetap directory and have fileshark
link to that instead of wiretap (but keep dissector source for now). Lots of
build configuration to mess with...
You are receiving this mail because:
- You are watching all bug changes.