Comment # 2
on bug 10159
from Anish Bhatt
(In reply to comment #1)
> Err, umm, so what would the bitmasks *do*? Mask out the bits of the
> individual characters?
The mask would only indicate which bits are responsible for the string, similar
to have VALS would have worked. Perhaps I am not being clear here, the sample
case is the bits indicate a string, but the actual string value is based on
more than one bit field.
>
> Note that FT_STRING* should *ONLY* be used for fields that are represented
> as character strings in the packet; they should *NOT* be used for fields
> that have integral values.
Gotcha, this would explain why bitmasks are not accepted.
>
> VALS() should be usable - define two separate hf_ values, with the *same*
> field name, and with *different* value_string tables, and use the
> appropriate one based on the subtype.
This was one of the solutions proposed. This creates problems with "Unknown"
type, no particular hf is correct there, had to resort to simply add_text,
which is no longer navigable.
The current solution results in a display of <field name> <bitmask_as_int>
<value_string> , when it should be <field name> <value_string>
I understand there may no one correct solution here, just a thought.
You are receiving this mail because:
- You are watching all bug changes.