> The problem is that 95% of the time the intended behaviour is best
> achieved by the reported length, but 95% of the time people new to the
> API pick up on tvb_length and friends and assume that's what they
I disagree. I find it not intuitive that a function called tvb_length() (the
propsed new version) would return a length, that the underlying data structure
does *not* have. This would be contrary to any other API working with an
array/buffer I know of. I also doubt that 95% of the use cases are asking for
reported/captured length. Personally I typically work on code to show the user
protocol (SSL, HTTP, DCE/RPC) and if a frame was truncated while capturing
(captured_length < actual_length) I can often not continue with dissecting the
user protocol, since I miss parts of the data.
I understand that there are good reasons to know about the actual length of the
frame and the captured length. I suggest that we simply state these lengths in
the function name and *not* have an unqualified (shorter) name which will get
misinterpreted. So my suggestion for a rename would be:
tvb_actual_length()
tvb_captured_length()
--
---> Dirk Jagdmann
----> http://cubic.org/~doj
-----> http://llg.cubic.org
