Re: Addressing FT_ types

[Alexis La Goutte <alexis.lagoutte () gmail com>]

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 decimal
> between 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 following
> could 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 decimal
> between 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 as
> hexadecimal.  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 be
> different "punctuation" BASEs between their byte values)
> > I'm looking for the "best", or at least "most consistent" approach.  I
> also 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