mailing list archives
Re: RFC: new types for hfi->display (STR_ASCII, STR_UNICODE), drop proto_tree_add_unicode_string()
From: Jakub Zawadzki <darkjames-ws () darkjames pl>
Date: Sat, 7 Dec 2013 18:02:08 +0100
On Sat, Dec 07, 2013 at 10:58:35AM -0500, Evan Huus wrote:
On Sat, Dec 7, 2013 at 7:20 AM, Jakub Zawadzki
<darkjames-ws () darkjames pl> wrote:
I renamed base_display_e to field_display_e, and added new enums to field_display_e,
but I wonder if it's correct approach.
For FT_ABSOLUTE_TIME we're using seperate enum
(absolute_time_display_e), so maybe FT_STRING* should also have own enum string_display_e ?
We already have ENC_ASCII, ENC_UTF8, etc. Perhaps
proto_tree_add_string should just take an encoding value instead?
Primarly STR_UNICODE is used only during filling label (+ one assertion),
and when displaying we have no longer information about ENC_* flag.
We could copy it to ->flags, but ->display for strings is wasted, why not use it?
We can later add STR_ASCII_WSP or bitmask like: STR_SHOW_LEN, etc..
We could avoid STR_UNICODE by adding encoding flags like you suggest,
and by fixing tvb_get_string[z]_enc to enforce encoding rules.
Like ENC_ASCII -> replace all chr >= 0x80
ENC_UTF8 -> replace invalid UTF-8 sequence
and so on..
 or by forcing users to call proto_tree_add_string() only with string earlier obtained from tvb_get_string[z]_enc().
Which I think is better solution.
Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org>
mailto:wireshark-dev-request () wireshark org?subject=unsubscribe