Re: Rename TVB captured length vs reported length

[Guy Harris <guy () alum mit edu>]

On Feb 18, 2014, at 2:00 PM, Dirk Jagdmann <doj () cubic org> 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 <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe