Re: Addressing FT_ types

[mmann78 () netscape net]

Ok, so I'm trying to go down the route of adding different "BASE" types for FT_BYTES.  I thought it would be fairly 
straightforward, but the problem I'm running into is that fvalue_to_string_repr() never gets the "BASE" value so I can 
distinguish between BASE_NONE, BASE_DOT and BASE_DASH.

Could it be as simple as just adding another parameter to fvalue_to_string_repr?  Grepping where fvalue_to_string_repr 
is used seems to indicate that not all calls to it will have "BASE" value available. 

Wanted to ask for guidance before I go down some errant rabbit holes (or just not completely understand all of the uses 
of fvalue_to_string_repr).
 
 
 
-----Original Message-----
From: Alexis La Goutte <alexis.lagoutte () gmail com>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Sent: Tue, Dec 30, 2014 4:47 am
Subject: Re: [Wireshark-dev] Addressing FT_ types


 
  
   
    
    
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
 

___________________________________________________________________________
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