> { &hf_sna_th_fid,
> { "Format Identifer", "sna.th.fid", FT_UINT8, NULL, mask, width, shift }}
Presumably (as per your later comment) the presence or absence of a
"val_string" would indicate whether it was numeric or enumerated.
FT_BOOLEAN could be used for Boolean bitfields; you might want some way
of specifying the strings for "true" and "false" - alas, standard C
doesn't have a good way of initializing unions (it has one sufficient to
allow the standard to say which element gets initialized to its version
of zero, but that's it), so replacing "vals" in the "header_field_info"
structure with a union of "struct value_string *" and, say, a pointer to
an array of two "char *"s would be painful - but making it a "void *",
although it might remove some type checking, would work.
> The shifting might come more into play with an "enumerated" bitfield that
> uses a val_string.
Actually, one problem there is that, currently, the bitfield *isn't*
shifted before being compared with the values in the "val_string" array.
For display purposes, the shifting isn't necessary for enumerated
bitfields, as the value of the bitfield isn't displayed, just the
corresponding string from the "val_string" array, or "Unknown"; it's
actually more important for *numeric* bitfields, where you typically
want the value displayed shifted into the right position (e.g., the N(R)
and N(S) fields in the control field of xDLC-family protocols, which is
why Olivier Abad put in code to shift it into the right position).
