On Fri, Apr 4, 2014 at 10:30 AM, Hadriel Kaplan
<hadriel.kaplan@xxxxxxxxxx> wrote:
> 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?
I guess not, since nobody's ever written them. If you can find enough
cases to make them worthwhile go right ahead :)
Evan