Re: unit_name_string for FT_STRING field types?

[Michael Mann via Wireshark-dev <wireshark-dev () wireshark org>]

Are you suggesting "unit types" for "strings" or are you suggesting "unit types" for "string values that should really 
be considered integers or floats"?
 
It certainly sounds like the latter and in which case I would suggest converting them in your dissector.  Numeric 
fields that are treated as numbers have more flexibility with comparison and math operations.

To me there isn't an argument here to have support for "true" strings and the proto_tree_add_string_format or 
proto_tree_add_string_format_value seems more appropriate.
 
 
 
-----Original Message-----
From: John Dill <John.Dill () greenfieldeng com>
To: wireshark-dev <wireshark-dev () wireshark org>
Sent: Mon, Sep 11, 2017 4:56 pm
Subject: [Wireshark-dev] unit_name_string for FT_STRING field types?



I have a dissector for a protocol sending packets containing ASCII strings of a delimited format over a TCP stream.
 
/AREA/NAME/FILLED/GREEN/1/2000/4000//
 
Sometimes the values are floating point, like
 
/ENV/-/-/1.0/90.0/100.0/-/-/-/5000.0//
 
I'm dissecting the format ok, but I can't use unit_name_string for these FT_STRING defined header fields.
 
I see (in 2.4.1) that unit_name_string is disabled for FT_STRING (​tmp_fld_check_assert is not allowing 
hfinfo->strings), so I've been using proto_tree_add_string_format..., but wondering if there's potential to allow 
FT_STRING to use unit_name_string.
 
One could classify the string contents as an integer or floating point value to pass to one of these functions:
 
unit_name_string_get_value
unit_name_string_get_value64
unit_name_string_get_double
 
If the string is not a valid number, or out of range, I'm not sure what the proper error behavior should be.  Could be 
to ignore the 'strings' value, throw an assert, or malformed packet.  It's possible that a value is missing '-' but I 
wouldn't want it to mark the packet as bogus because of it.
 
Mostly, it'd be easier putting the units in the header field definition instead of having a separate table of header 
field -> unit_name_string for these FT_STRING types and doing the checking/formatting myself.
 
Does this idea seem compatible with proto.c?
 
Thanks,
John Dill
 

___________________________________________________________________________Sent via:    Wireshark-dev mailing list 
<wireshark-dev () wireshark org>Archives:    https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.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:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe