On Thu, Nov 19, 2015 at 9:57 PM, Michael Mann <mman...@netscape.net> wrote: > This question has probably been asked before, so I thought I'd at least put > a Tennyson twist on it. > > I started getting more serious about converting dissectors to the "new > style". I submitted a bunch of patches where it was obvious that the > dissectors fell into the "give me everything" category. My biggest worry is > the comment made by Guy in bug 11134 > (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11134#c13), that some > dissectors want to "accept" a tvb (packet) as their own, but don't actually > parse any bytes (so it appears that they would "return 0" with the new > style). So the remaining ones I'm taking more slowly (with the attitude of > unsure means leave as old style) and if anyone know of protocols that behave > this way, feel free to convert them (or send me a note) > > The case I keep coming across that I'm not sure how to deal with is > dissectors that get a few bytes in (and have already created trees/items for > a few fields), and then decide they aren't going to dissect anymore because > of a "bad" field value (most commonly "version" or "length"). Should we > apply a consistent rule for this? Like if you're not going to dissect > "versions" you don't support, check before making trees and just not bother > with expert info saying "version isn't supported" while ceasing dissection. > Or dissect as "latest version" (or at least "a" version), but with the > expert info applied that the version is unknown. I'm not sure which > scenario users would appreciate more, but I'd like to see it applied as > consistently as possible. I believe my preference is for using expert info, > but continuing dissection.
I'm OK with that. > Are such rules more critical for popular protocols like Ethernet, IP and > TCP/UDP where there are possibly "shared" values for a subdissector > identifier? > > Also, should we clean up a tree if a new-style dissector returns 0 (within > the functions in epan/packet.c)? I think the expert info would be harder to > clean up, but I'm also not sure of the difficult of the trees either. As Guy said, a dissector should not be returning 0 if it's added any tree items. If we can tell when this occurs, we should make it a DISSECTOR_BUG. > Opinions welcome, but I'd like to see the "new" style be the "only" style by > the 2.2 release. This would be amazing. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe