Re: [Wireshark-dev] [Wireshark-commits] master f412c9a: Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...

2014-12-13 Thread Evan Huus
I didn't think single-byte fields could really have an endianess, so I
thought ENC_NA was appropriate for them?

Evan

On Sat, Dec 13, 2014 at 1:45 PM, Wireshark code review
 wrote:
> URL: 
> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=f412c9a01aa031ef9f024ee1b8ec60bf4a73edb8
> Submitter: Bill Meier (wme...@newsguy.com)
> Changed: branch: master
> Repository: wireshark
>
> Commits:
>
> f412c9a by Bill Meier (wme...@newsguy.com):
>
> Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...
>
>   (for some dissectors which fetch all other integral fields using
>ENC_BIG_ENDIAN).
>
> Change-Id: Ic18e3172aad76af12b12d6732c88497be22aed56
> Reviewed-on: https://code.wireshark.org/review/5748
> Reviewed-by: Bill Meier 
>
>
> Actions performed:
>
> from  7592d39   GSM SMS: fix 'msg_class' may be used uninitialized in 
> this function warning
> adds  f412c9a   Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...
>
>
> Summary of changes:
>  epan/dissectors/packet-6lowpan.c   |2 +-
>  epan/dissectors/packet-acr122.c|   10 +-
>  epan/dissectors/packet-aim-generic.c   |2 +-
>  epan/dissectors/packet-ansi_801.c  |   68 ++---
>  epan/dissectors/packet-aodv.c  |2 +-
>  epan/dissectors/packet-arp.c   |8 +-
>  epan/dissectors/packet-aruba-erm.c |4 +-
>  epan/dissectors/packet-asterix.c   |2 +-
>  epan/dissectors/packet-auto_rp.c   |2 +-
>  epan/dissectors/packet-babel.c |   28 +-
>  epan/dissectors/packet-batadv.c|4 +-
>  epan/dissectors/packet-bgp.c   |   42 +--
>  epan/dissectors/packet-bzr.c   |4 +-
>  epan/dissectors/packet-carp.c  |2 +-
>  epan/dissectors/packet-cdp.c   |   20 +-
>  epan/dissectors/packet-chdlc.c |2 +-
>  epan/dissectors/packet-clnp.c  |2 +-
>  epan/dissectors/packet-cops.c  |   24 +-
>  epan/dissectors/packet-dcm.c   |   18 +-
>  epan/dissectors/packet-dhcp-failover.c |2 +-
>  epan/dissectors/packet-diameter_3gpp.c |2 +-
>  epan/dissectors/packet-dis.c   |   50 ++--
>  epan/dissectors/packet-dlsw.c  |   52 ++--
>  epan/dissectors/packet-dns.c   |   28 +-
>  epan/dissectors/packet-dtn.c   |4 +-
>  epan/dissectors/packet-dtp.c   |8 +-
>  epan/dissectors/packet-elmi.c  |2 +-
>  epan/dissectors/packet-epon.c  |2 +-
>  epan/dissectors/packet-erldp.c |4 +-
>  epan/dissectors/packet-etch.c  |6 +-
>  epan/dissectors/packet-etsi_card_app_toolkit.c |   56 ++--
>  epan/dissectors/packet-fcels.c |   26 +-
>  epan/dissectors/packet-fcswils.c   |   22 +-
>  epan/dissectors/packet-fmtp.c  |6 +-
>  epan/dissectors/packet-foundry.c   |4 +-
>  epan/dissectors/packet-giop.c  |   10 +-
>  epan/dissectors/packet-gmr1_common.c   |2 +-
>  epan/dissectors/packet-gsm_a_dtap.c|   72 ++---
>  epan/dissectors/packet-gsm_a_gm.c  |4 +-
>  epan/dissectors/packet-gsm_a_rr.c  |   16 +-
>  epan/dissectors/packet-gsm_sim.c   |6 +-
>  epan/dissectors/packet-gtp.c   |   48 ++--
>  epan/dissectors/packet-gtpv2.c |   10 +-
>  epan/dissectors/packet-h264.c  |4 +-
>  epan/dissectors/packet-hpsw.c  |2 +-
>  epan/dissectors/packet-http2.c |   30 +--
>  epan/dissectors/packet-iapp.c  |4 +-
>  epan/dissectors/packet-igmp.c  |2 +-
>  epan/dissectors/packet-igrp.c  |   10 +-
>  epan/dissectors/packet-ipp.c   |2 +-
>  epan/dissectors/packet-ipv6.c  |   22 +-
>  epan/dissectors/packet-isis-hello.c|   28 +-
>  epan/dissectors/packet-isis-lsp.c  |   42 +--
>  epan/dissectors/packet-isl.c   |6 +-
>  epan/dissectors/packet-kink.c  |4 +-
>  epan/dissectors/packet-knxnetip.c  |2 +-
>  epan/dissectors/packet-l2tp.c  |   10 +-
>  epan/dissectors/packet-lacp.c  |   16 +-
>  epan/dissectors/packet-lisp-tcp.c  |2 +-
>  epan/dissectors/packet-lisp.c  |   32 +--
>  epan/dissectors/packet-llrp.c  |   16 +-
>  epan/dissectors/packet-lmp.c   |   20 +-
>  epan/dissectors/packet-lon.c   |   54 ++--
>  epan/dissectors/packet-maccontrol.c|   10 +-
>  epan/dissectors/packet-macsec.c|   16 +-
>  epan/dissectors/packet-marker.c|4 +-
>  epan/dissectors/

Re: [Wireshark-dev] [Wireshark-commits] master f412c9a: Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...

2014-12-14 Thread Bill Meier

On 12/13/2014 4:56 PM, Evan Huus wrote:

I didn't think single-byte fields could really have an endianess, so I
thought ENC_NA was appropriate for them?

Evan



Using ENC_NA is certainly reasonable (and makes logical sense) for 
fetching single-byte fields.


That being said, the convention (certainly not enforced) seems to be to 
use ENC_..._ENDIAN for fetching all integral types.


Looking at the current (non-generated) dissector source before I started 
making changes, I noted that the usage for singe-byte fetches (for 
proto_tree_add_item(), etc) was more or less as follows:


ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN:~12.5K
ENC_NA   ~ 2.7K

I also noted that the ASN.1 generated dissectors appear to be using the 
ENC_..._ENDIAN convention as well when fetching single-byte fields.


--

If there's a consensus that ENC_NA should be used when fetching 
single-byte fields, it might be a bit of work, but probably fairly 
simple to do a wholesale change


Bill


___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


Re: [Wireshark-dev] [Wireshark-commits] master f412c9a: Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...

2014-12-14 Thread Stephen Fisher
On Sun, Dec 14, 2014 at 01:44:19PM -0500, Bill Meier wrote:

> That being said, the convention (certainly not enforced) seems to be 
> to use ENC_..._ENDIAN for fetching all integral types.

Could this be related to when we made the change from using FALSE / TRUE 
to specify if its "big endian" in things like proto_tree_add_item() ?
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


Re: [Wireshark-dev] [Wireshark-commits] master f412c9a: Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...

2014-12-14 Thread Bill Meier

On 12/14/2014 2:22 PM, Stephen Fisher wrote:

On Sun, Dec 14, 2014 at 01:44:19PM -0500, Bill Meier wrote:


That being said, the convention (certainly not enforced) seems to be
to use ENC_..._ENDIAN for fetching all integral types.


Could this be related to when we made the change from using FALSE / TRUE
to specify if its "big endian" in things like proto_tree_add_item() ?



Good point !

fix-encoding-args.pl (used to do the change) just converted FALSE|0 to 
BIG_ENDIAN and etc, so the "convention" actually kind-of-happened 
because previously TRUE|1 or FALSE|0 were the only choices for the 
'encoding-arg".


So, I stand corrected.

Maybe what I should be doing is converting all the single-byte fetches 
to use ENC_NA.


Thoughts ?

Bill


___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


Re: [Wireshark-dev] [Wireshark-commits] master f412c9a: Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...

2014-12-14 Thread Anders Broman
Den 14 dec 2014 21:03 skrev "Bill Meier" :
>
> On 12/14/2014 2:22 PM, Stephen Fisher wrote:
>>
>> On Sun, Dec 14, 2014 at 01:44:19PM -0500, Bill Meier wrote:
>>
>>> That being said, the convention (certainly not enforced) seems to be
>>> to use ENC_..._ENDIAN for fetching all integral types.
>>
>>
>> Could this be related to when we made the change from using FALSE / TRUE
>> to specify if its "big endian" in things like proto_tree_add_item() ?
>
>
>
> Good point !
>
> fix-encoding-args.pl (used to do the change) just converted FALSE|0 to
BIG_ENDIAN and etc, so the "convention" actually kind-of-happened because
previously TRUE|1 or FALSE|0 were the only choices for the 'encoding-arg".
>
> So, I stand corrected.
>
> Maybe what I should be doing is converting all the single-byte fetches to
use ENC_NA.
>
> Thoughts ?
>
> Bill
>
>

To me using the same endianess as beeing used for other integers in the
dissector would make the most sense.
Regards
Anders

>
>
___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master f412c9a: Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...

2014-12-14 Thread Evan Huus
On Dec 14, 2014 3:04 PM, "Bill Meier"  wrote:
>
> On 12/14/2014 2:22 PM, Stephen Fisher wrote:
>>
>> On Sun, Dec 14, 2014 at 01:44:19PM -0500, Bill Meier wrote:
>>
>>> That being said, the convention (certainly not enforced) seems to be
>>> to use ENC_..._ENDIAN for fetching all integral types.
>>
>>
>> Could this be related to when we made the change from using FALSE / TRUE
>> to specify if its "big endian" in things like proto_tree_add_item() ?
>
>
>
> Good point !
>
> fix-encoding-args.pl (used to do the change) just converted FALSE|0 to
BIG_ENDIAN and etc, so the "convention" actually kind-of-happened because
previously TRUE|1 or FALSE|0 were the only choices for the 'encoding-arg".
>
> So, I stand corrected.
>
> Maybe what I should be doing is converting all the single-byte fetches to
use ENC_NA.
>
> Thoughts ?

This makes sense to me.

> Bill
>
>
>
>
___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master f412c9a: Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...

2014-12-14 Thread Jeff Morriss

On 12/14/2014 03:03 PM, Bill Meier wrote:

On 12/14/2014 2:22 PM, Stephen Fisher wrote:

On Sun, Dec 14, 2014 at 01:44:19PM -0500, Bill Meier wrote:


That being said, the convention (certainly not enforced) seems to be
to use ENC_..._ENDIAN for fetching all integral types.


Could this be related to when we made the change from using FALSE / TRUE
to specify if its "big endian" in things like proto_tree_add_item() ?



Good point !

fix-encoding-args.pl (used to do the change) just converted FALSE|0 to
BIG_ENDIAN and etc, so the "convention" actually kind-of-happened
because previously TRUE|1 or FALSE|0 were the only choices for the
'encoding-arg".

So, I stand corrected.

Maybe what I should be doing is converting all the single-byte fetches
to use ENC_NA.

Thoughts ?


We discussed this some time ago; the consensus at the time seemed to be 
use ENC_*_ENDIAN for 1-byte fields:


https://www.wireshark.org/lists/wireshark-dev/201107/msg00404.html

___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


Re: [Wireshark-dev] [Wireshark-commits] master f412c9a: Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...

2014-12-14 Thread Michal Labedzki
Personally I prefer ENC_NA for single-byte. Some dissectors can mix
endianess, like file-elf. What use in case like that?

Maybe there is a need to add something new like ENC_NO_ENDIAN?
(ENC_HOST_ENDIAN?)
 That can be used to fetch value that is always in host endian (magic number?)

By the way: I use ENC_NA to improve readability too. I take a quick
look and see my single-byte field, where around is a lot of multibyte
fields.

About copy-paste bugs: now there is a guard like Petri-Dish/pre-commit.

On 15 December 2014 at 01:43, Jeff Morriss  wrote:
> On 12/14/2014 03:03 PM, Bill Meier wrote:
>>
>> On 12/14/2014 2:22 PM, Stephen Fisher wrote:
>>>
>>> On Sun, Dec 14, 2014 at 01:44:19PM -0500, Bill Meier wrote:
>>>
 That being said, the convention (certainly not enforced) seems to be
 to use ENC_..._ENDIAN for fetching all integral types.
>>>
>>>
>>> Could this be related to when we made the change from using FALSE / TRUE
>>> to specify if its "big endian" in things like proto_tree_add_item() ?
>>
>>
>>
>> Good point !
>>
>> fix-encoding-args.pl (used to do the change) just converted FALSE|0 to
>> BIG_ENDIAN and etc, so the "convention" actually kind-of-happened
>> because previously TRUE|1 or FALSE|0 were the only choices for the
>> 'encoding-arg".
>>
>> So, I stand corrected.
>>
>> Maybe what I should be doing is converting all the single-byte fetches
>> to use ENC_NA.
>>
>> Thoughts ?
>
>
> We discussed this some time ago; the consensus at the time seemed to be use
> ENC_*_ENDIAN for 1-byte fields:
>
> https://www.wireshark.org/lists/wireshark-dev/201107/msg00404.html
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe



-- 

Pozdrawiam / Best regards
-
Michał Łabędzki, Software Engineer
Tieto Corporation

Product Development Services

http://www.tieto.com / http://www.tieto.pl
---
ASCII: Michal Labedzki
location: Swobodna 1 Street, 50-088 Wrocław, Poland
room: 5.01 (desk next to 5.08)
---
Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, you are hereby
notified that any unauthorised use, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to
the message and deleting it from your computer. Thank You.
---
Please consider the environment before printing this e-mail.
---
Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w
Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym
Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego
Rejestru Sądowego pod numerem 124858. NIP: 8542085557. REGON:
812023656. Kapitał zakładowy: 4 271500 PLN
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master f412c9a: Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...

2014-12-14 Thread Alexis La Goutte
Hi,

I prefer also ENC_NA for single-byte.
I think, it will be complicated to have a automatically tools for check if
ENC_BIG_ENDIAN and ENC_LITTLE_ENDIAN will be autorise..

Yes, Petri-dish/pre-commit is guard but need all people use it...

Regards,

On Mon, Dec 15, 2014 at 8:23 AM, Michal Labedzki 
wrote:
>
> Personally I prefer ENC_NA for single-byte. Some dissectors can mix
> endianess, like file-elf. What use in case like that?
>
> Maybe there is a need to add something new like ENC_NO_ENDIAN?
> (ENC_HOST_ENDIAN?)
>  That can be used to fetch value that is always in host endian (magic
> number?)
>
> By the way: I use ENC_NA to improve readability too. I take a quick
> look and see my single-byte field, where around is a lot of multibyte
> fields.
>
> About copy-paste bugs: now there is a guard like Petri-Dish/pre-commit.
>
> On 15 December 2014 at 01:43, Jeff Morriss 
> wrote:
> > On 12/14/2014 03:03 PM, Bill Meier wrote:
> >>
> >> On 12/14/2014 2:22 PM, Stephen Fisher wrote:
> >>>
> >>> On Sun, Dec 14, 2014 at 01:44:19PM -0500, Bill Meier wrote:
> >>>
>  That being said, the convention (certainly not enforced) seems to be
>  to use ENC_..._ENDIAN for fetching all integral types.
> >>>
> >>>
> >>> Could this be related to when we made the change from using FALSE /
> TRUE
> >>> to specify if its "big endian" in things like proto_tree_add_item() ?
> >>
> >>
> >>
> >> Good point !
> >>
> >> fix-encoding-args.pl (used to do the change) just converted FALSE|0 to
> >> BIG_ENDIAN and etc, so the "convention" actually kind-of-happened
> >> because previously TRUE|1 or FALSE|0 were the only choices for the
> >> 'encoding-arg".
> >>
> >> So, I stand corrected.
> >>
> >> Maybe what I should be doing is converting all the single-byte fetches
> >> to use ENC_NA.
> >>
> >> Thoughts ?
> >
> >
> > We discussed this some time ago; the consensus at the time seemed to be
> use
> > ENC_*_ENDIAN for 1-byte fields:
> >
> > https://www.wireshark.org/lists/wireshark-dev/201107/msg00404.html
> >
> >
> >
> ___
> > Sent via:Wireshark-dev mailing list 
> > Archives:http://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> > mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
>
>
> --
>
> Pozdrawiam / Best regards
>
> -
> Michał Łabędzki, Software Engineer
> Tieto Corporation
>
> Product Development Services
>
> http://www.tieto.com / http://www.tieto.pl
> ---
> ASCII: Michal Labedzki
> location: Swobodna 1 Street, 50-088 Wrocław, Poland
> room: 5.01 (desk next to 5.08)
> ---
> Please note: The information contained in this message may be legally
> privileged and confidential and protected from disclosure. If the
> reader of this message is not the intended recipient, you are hereby
> notified that any unauthorised use, distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please notify us immediately by replying to
> the message and deleting it from your computer. Thank You.
> ---
> Please consider the environment before printing this e-mail.
> ---
> Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w
> Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym
> Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego
> Rejestru Sądowego pod numerem 124858. NIP: 8542085557. REGON:
> 812023656. Kapitał zakładowy: 4 271500 PLN
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master f412c9a: Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...

2014-12-15 Thread Graham Bloice
On 15 December 2014 at 07:52, Alexis La Goutte 
wrote:

>
>
> Yes, Petri-dish/pre-commit is guard but need all people use it...
>
>
+1

-- 
Graham Bloice
___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master f412c9a: Use ENC_BIG_ENDIAN when fetching FT_U?INT8 fields ...

2014-12-15 Thread Stephen Fisher
On Mon, Dec 15, 2014 at 08:23:47AM +0100, Michal Labedzki wrote:

> Personally I prefer ENC_NA for single-byte.

Me too.  How about changing proto_tree_add_item() so that the endian 
field is optional?

Single byte:

  proto_tree_add_item(tree, proto_test, tvb, 0, 1);

Multi-byte:

  proto_tree_add_item(tree, proto_test, tvb, 1, 2, ENC_BIG_ENDIAN);

___
Sent via:Wireshark-dev mailing list 
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe