http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1539
Josh Moore <jmoore@xxxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jmoore@xxxxxxxxxxxx
--- Comment #5 from Josh Moore <jmoore@xxxxxxxxxxxx> 2008-03-26 18:23:32 GMT ---
I disagree with how this bug was resolved/fixed. Instead of disallowing the use
of FT_INT8, FT_INT16, FT_INT24, and FT_INT32 with BASE_DEC_HEX and
BASE_HEX_DEC, I think that the "underlying bug (filter prep?)" should be fixed
instead.
Why did you decide that forcing developers to use UINT for values that will
display in hex was the right solution? When someone wants to make 0xffff
display, did you get tired of arguing over whether to display 0xffff (2’s
complement for -1), or -0x0001 (a unary negation operator on the value +1)? Or,
did it just seem to be the easier of the two to change?
For example, if I have a integer (representing, in this case, the real world
example of a discriminator position) that has range -100 or so to about +100,
I want it displayed in both integer form and the host byte order hexedecimal
two's complement form. BASE_DEC_HEX was perfect for this. When its value is -1,
I would see something like this in the tree:
Discriminator 1: -1 (0xffff)
Now, if I change from FT_INT16 to FT_UINT16, I get this horrible output:
Discriminator 1: 65535 (0xffff)
This is the only way to get the hexedecimal display to work in this new scheme.
You have to break the decimal display by telling it to interpret the number as
positive instead of negative.
I would *NOT* want to see the representation someone mentioned below,
Discriminator 1: -1 (-0x0001)
This bad representation does not represent the byte values of the variables at
all.
You can see some mention of this in epan/proto.c tmp_fld_check_assert().
Comments are welcome; for now I have changed my dissectors to FT_UINT* and I
use proto_tree_add_int_format() to format such readings myself:
discrim_value = tvb_get_letohs(tvb, start_idx);
proto_tree_add_int_format(discrim_subtree,
hf_discrim_value, tvb, start_idx, 4, discrim_value,
".... .... .... .... %c%c%c%c %c%c%c%c %c%c%c%c %c%c%c%c =
Discriminator %d value: %hd (0x%.4hx)",
discrim_value&0x8000?'1':'0', discrim_value&0x4000?'1':'0',
discrim_value&0x2000?'1':'0', discrim_value&0x1000?'1':'0',
discrim_value&0x0800?'1':'0', discrim_value&0x0400?'1':'0',
discrim_value&0x0200?'1':'0', discrim_value&0x0100?'1':'0',
discrim_value&0x0080?'1':'0', discrim_value&0x0040?'1':'0',
discrim_value&0x0020?'1':'0', discrim_value&0x0010?'1':'0',
discrim_value&0x0008?'1':'0', discrim_value&0x0004?'1':'0',
discrim_value&0x0002?'1':'0', discrim_value&0x0001?'1':'0',
discrim_num, discrim_value, discrim_value);
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.