Hi,
I might be overlooking something, but I don’t see a tvb_get_* function to get a uint8/16/32/64 that was encoded as a ascii or utf-8 string in the packet. Is there such a thing?
Instead, it seems the dissectors that deal with string messages do a tvb_get_string_enc() or tvb_format_text(), and then a strtol() or atoi(). But in my way of thinking, the fact that it’s in a string-encoded form in the tvb isn’t that much different from it being encoded as little-endian vs. network-order.
Likewise, it’s not clear if there’s a way to define a protocol field that is encoded as a string in the packet but is internally a uint8/16/32/64 (e.g., for filtering purposes, val_string lookup, etc.). For example such that proto_tree_add_item() would work. Instead, it seems some dissectors use the returned strtol/atoi to then add the field to the tree as a true uint type, or add it as a FT_STRING field type.
And if we had common functions handle ascii and utf-8 string-encoded numbers, they could avoid creating temporary strings as well.
Are there just not enough such cases to make it worthwhile to have common functions for these?
-hadriel
