On Fri, Apr 4, 2014 at 10:30 AM, Hadriel Kaplan <hadriel.kap...@oracle.com> 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 ___________________________________________________________________________ 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
