Comment # 6
on bug 10159
from Guy Harris
(In reply to comment #5)
> > Presumably by ""Unknown" type" you mean "a subtype for which there's no
> > correct value_string table"; if so, then create an hf_ with an *empty*
> > value_string table, so that *everything* shows up as "Unknown".
>
> Yes, that's what I meant. But now we have 3 hf_'s, an optional val_string
> and requisite code to display 4 strings and an unknown. The unknown itself
> could have variations. That seems like a lot of code addition for a simple
> problem.
>
> If I can use VALS() to display a string equivalent for a bitmask, surely the
> option to use a custom string instead is not too much to ask ?
The option to use FT_STRING* to handle a value stored as an integer bitfield
*is*, as far as I'm concerned, much too much to ask, and you'd still need to
have "requisite code" to decide what the subtype is, map the integral value to
a string, and add the string to the protocol tree. I.e., you're *still* going
to have a lot of code addition for a simple problem if you use FT_STRING*,
*and* you're going to have code that does some particularly horrid violence to
the type system for named fields.
If you want to use something more complicated than a value_string table to
display a text description of a bitfield's value, and don't want to use
multiple hf_'s, you could use proto_tree_add_uint_format_value() and format the
value yourself.
You are receiving this mail because:
- You are watching all bug changes.