On Feb 18, 2014, at 2:00 PM, Dirk Jagdmann <[email protected]> wrote: >> You *can* continue dissecting the protocol. You just get an exception, so >> that the user sees that the data was in the packet, but the snapshot length >> was set too short to capture it. Stopping dissection just because the data >> to be dissected was cut off by a snapshot length is entirely the wrong thing >> to do, as it can make it look as if the packet didn't have the data in >> question. > > That's my point. Not all of the code I have written will get executed, because > data is missing.
I.e., it won't get executed because code executed before it will throw a "ran past the end of the captured data" exception? > And if the next frame needs information from previous frames to > dissect, my dissection of the protocol stops here. Presumably it stops because a search for the previous data finds nothing, not because of a call to tvb_length() or tvb_length_remaining() returning 0 or a negative value. > Of course there's nothing I can do about it. I just wanted to point out, that > not only 5% is the dissector code requires access to all data to be useful. My > main point is however to not use "tvb_length" any more at all, because > different > developers will interpret it differently. Use the longer, but explicit > function > names. And use tvb_actual_length()/tvb_actual_length_remaining() in somewhere between 99.5 and 100% of the cases. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
