Wireshark mailing list archives
Re: Addressing FT_ types
From: Alexis La Goutte <alexis.lagoutte () gmail com>
Date: Tue, 30 Dec 2014 10:47:05 +0100
On Mon, Dec 29, 2014 at 6:35 PM, Pascal Quantin <pascal.quantin () gmail com> wrote:
Le 29 déc. 2014 16:59, <mmann78 () netscape net> a écrit :I was looking to add an FT_ enumeration for Fibre Channel addresses.See https://code.wireshark.org/review/6098/ for my attempt. Because the Fibre Channel address already had an "address type" (AT_FC), I thought a corresponding FT_ was appropriate. That seems to be how many of the "address types" are turned into field types. The review comments so far suggest that maybe an FT_ enumeration isn't the way to go, so I thought I'd pose the question to -dev.A Fibre Channel address is a 3 byte value, displayed with a decimalbetween each byte, displayed as hex values (ie ff.ff.ff). It does not have a "name resolution" component (like IP or Ethernet addresses).So if you're creating an hf_ item for it, I believe any of the followingcould be the way to represent it.1. FT_FC, BASE_NONE (current approach) 2a. FT_UINT24, BASE_DOT (Suggestion that BASE_DOT would but a decimalbetween each byte value). proto_tree_add_item using the hf_ field would need a ENC_BIG_ENDIAN parameter.2b. FT_UINT24, BASE_HEX|BASE_DOT (to ensure bytes are represented ashexadecimal. So an IPv4 address could be considered FT_UINT32, BASE_DEC|BASE_DOT if not for the name resolution)3. FT_BYTES, BASE_DOT (perhaps other address types could just bedifferent "punctuation" BASEs between their byte values)I'm looking for the "best", or at least "most consistent" approach. Ialso don't mind taking the time to change other existing methods to be able to identify/keep that consistency. Big picture is trying to cleanup address_to_str functionality as some of the comments in the code suggest.Hi, On my side I like option 3.
Hi, For me, don't add a new FT_ type if there is no "resolve functions" (like resolve name for IPv4/IPv6/ Ethernet/EUI64...) I like the option 3 too (add also BASE_DASH...) Regards,
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org ?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Addressing FT_ types mmann78 (Dec 29)
- Re: Addressing FT_ types Pascal Quantin (Dec 29)
- Re: Addressing FT_ types Alexis La Goutte (Dec 30)
- Re: Addressing FT_ types Pascal Quantin (Dec 29)