Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 39143: /trunk/epan/dissectors/ /trun
Martin Kaiser skrev 2011-09-26 23:28:
Dear all,
I wanted to discuss this as well to make sure that my next submissions
are in line with your policy, but you were faster ;-)
Thus wrote Maynard, Chris (Christopher.Maynard@xxxxxxxxx):
-----Original Message-----
From me:
Change ENC_NA to ENC_BIG_ENDIAN as i suppose this is a big endian
protocol and ENC_NA was erroneously used for irems bigger than i
byte
in some cases.
This is a good example of the problem that can occur with using
ENC_NA.
What problem can occur with ENC_NA here?
My assumption was that ENC_BIG_ENDIAN/_LITTLE_ENDIAN is only applicable
to multi-byte numeric values, i.e. FT_(U)INT16/32/64. For FT_(U)INT8 and
FT_BYTES, FT_STRING etc., I used ENC_NA.
In this case ENC_NA and ENC_BIG_ENDIAN does not make a difference as the
actual value of the symbol
is the same presently
+ proto_tree_add_item(
+ tree, hf_dvbci_sac_msg_ctr, tvb, offset, 4, ENC_NA);
is wrong in principle as it's a multi byte field. Personally I think it
makes sense to tag the one byte fields the
same as the bulk of the multi byte fields in the dissector e.g
ENC_BIG_ENDIAN or ENC_LITTLE_ENDIAN as it makes
the code more symmetrical and easier to read ( avoids "Hmm why is this
field ENC_NA").
In the case of
proto_tree_add_item(tree, hf_dvbci_file_hash,
- tvb, offset, 16, ENC_NA);
+ tvb, offset, 16, ENC_BIG_ENDIAN);
I made a mistake as that's a FT_BYTES it should be ENC_NA I suppose. So
you might want to check your code
and fix it in your next patch ;-)
Best regards
Anders
Anders' assumption is correct: all multi-byte values in DVB-CI are big
endian.
Best regards,
Martin
___________________________________________________________________________
Sent via: Wireshark-dev mailing list<wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
