Wireshark-bugs: [Wireshark-bugs] [Bug 9446] Bluetooth: Improve/Little bugfix of HCRP, OBEX, HCI
Michael Mann
changed
bug 9446
| What |
Removed |
Added |
| CC |
|
mmann78@netscape.net
|
Comment # 9
on bug 9446
from Michael Mann
(In reply to comment #8)
> By the way: also interesting idea is replace "*data"
> by "p_add/get_proto_data", but I am not sure if it is optimal way to share
> data between dissectors:
Passing data via the "data" parameter in new style dissectors should ALWAYS be
your first choice when exchanging data between dissectors. It makes code flow
much easier to follow and limits the possibility of "globals" (technically a
smaller scope than true globals, but the same principle applies) being
overwritten/corrupted by exceptions.
> Pros: no needed to pass some data between
> dissectors, for example: from bthci_acl via btl2cap and btrfcomm to bthfp
> (btl2cap, btrfcomm does not use this data)
If you have a subdissector table, it's up to the "parent" to decide what to
pass to its subdissectors. "Children" may have influence but they are free to
ignore it. For example there are a few dissectors than need TCP header data,
so it ends up getting past to all TCP subdissectors. No harm in dissectors
ignoring it.
If you are calling a specific subdissector by handle, then you can decide not
to pass data from "parent" to "child"
> Cons: p_*_proto_data use list
> and allocation - may be more expensive
The original intent of the new p_*_proto_data functions (r53520) was to
exchange data with the GUI (Decode As), NOT other dissectors. I've been trying
really hard to move "obviously protocol specfic memebers" of packet_info to
data parameters of dissectors and not get lazy and just convert them to "proto"
data with packet_scope (although a few may end up that way)
You are receiving this mail because:
- You are watching all bug changes.
