https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6082
--- Comment #14 from Bill Meier <wmeier@xxxxxxxxxxx> 2011-11-14 09:33:40 EST ---
(In reply to comment #12)
> (In reply to comment #11)
> > There is a problem in the length-decoding.
> > Before I submit a patch I would like to ask you if there is a specific reeason
> > for decoding the port (hf_netanalyzer_port) and length (hf_netanalyer_length)
> > as bit-field using proto_tree_add_item. In my original version I uses
> > proto_tree_add_unit in order to avoid displaying the bit-fields. For this case
> > the bit-field display does not make much sense for the user. I would appreciate
> > to use my original implementation for that, is that ok?
> I suppose, but to me displaying it as a bit field seems like the right thing
> to do, the port is the first two bits isn't it? perhaps the field should just
> be 8 bits wide?
> Regards
> Anders
My feeling is the same as Anders;
IMHO, in general, the detail pane should show the actual bits from which a
field is obtained (when the field is something other than 8 bits aligned on
some 8 bit boundary).
The summary line does show the port number & etc so that the user does not need
to look at the details (expand the tree) unless desired.
=====
I'm curious as to what's wrong with the length display. Based upon the
description in the source file and to match the summary line display, I changed
the display using proto_tree_add_item() to be little-endian.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.