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.d...@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-requ...@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-requ...@wireshark.org?subject=unsubscribe
