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 ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
