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
