On Wed, 02 Jan 2002 17:48:31 Tim Potter wrote:
> I'm just wondering why length arguments are typed as gint's when
> accessing tvb data. My scenario is this: I have either a corrupted
> packet or a dodgy dissector which is reading the value 0x9c6f6f90 as a
> length. The dissector then does:
The idea is to allow -1 to mean "to the end of the data". No other
negative numbers are allowed for lengths.
>
> ptr = tvb_get_ptr(tvb, offset, count);
>
> with the above value for count. This causes ethereal to abort with an
> assertion in compute_offset_length() as it's asserting length >= -1.
>
> I think the dissector should throw an exception because there is not
> enough data in the tvb to satisfy the tvb_get_ptr() request.
>
You're right. I didn't think of this situation when writing the tvbuff
code.
It should thrown an exception. Our current tvbuff-related exceptions,
BoundsError and ReportedBoundsError, don't seem to fit for this case,
which is bad data passed to the tvbuff API (since the only negative length
allowed is -1). I could add a new exception, say InvalidValueError, or
OutOfRangeError, or perhaps more specifically, NegativeLengthError.
The frame dissector in packet-frame.c would catch this new exception
and add the appropriate text to the protocol tree.
I'll make some modifications and do some regression testing while we
debate the name of the new exception.
--gilbert
