On Feb 18, 2014, at 2:00 PM, Dirk Jagdmann <doj@xxxxxxxxx> 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.
