On Oct 10, 2011, at 2:06 PM, Ed Beroset wrote:
> Perhaps it's a bit late, but if this only affects hf_ variables when used
> within proto_add_item() calls, might it make more sense to keep this
> information within the hf_register_info struct?
If you mean "might it make more sense to keep all encoding information *solely*
within the hf_register_info structure and get rid of the encoding argument to
proto_tree_add_item()", the answer is "no"; there are protocols for which not
all instances of a given field in all captures use the same encoding (whilst
one could have multiple instances of the same field, with different encodings,
and choose which one to use at run time, the prospect of fixing bug 6084 by
introducing duplicates of all string fields and having all calls that add
string fields choose which instance to use based on the character encoding
struck me as such a pain that I introduced ENC_EBCDIC and ENC_UTF_8 and went
with having a single encoding variable for strings and using that in all the
proto_tree_add_item() calls).
If you mean "might it make sense to provide encoding information in the
hf_register_info structure, have calls to add items using the "default"
encoding in the hf_register_info, and calls to add items with a
run-time-specified encoding that overrides the default", that might be the case.
Another possibility might be to make more use of the ptvcursor routines, add
encoding information to the ptvcursor, and have ptvcursor routines that add
items using the encoding from the ptvcursor and routines that add items using a
run-time-specified encoding, or have calls that push and pop encodings, or....
This is somewhat like the way byte order is specified in WSGD:
http://wsgd.free.fr/
where there's a command to specify a byte order globally:
http://wsgd.free.fr/fdesc_format.html#cmd
that can be individually overriden for a particular field:
http://wsgd.free.fr/fdesc_format.html#byte_order_local
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
