Do you mean that, for a given field that contains Boolean bitfields, you'd
have a single array that contains values for all the Boolean bitfields in
that field, and have the "hf_register_info" values for all those bitfields
refer to that array?
This would be an interesting integration of the bitfield_string
utility I posted a while back. I'm still trying to figure out the
best way to do that. It duplicates a little bit of the
hf_register_info functionality, mostly because (a) it was originally
intended to provide a single definition for both short text listing
and longer tree detail, and (b) because there's no way to query the
hf_register_info registry for a field name when formatting your own
items. I should probably revisit the former, because it turns out
that the short and long versions are often sufficiently different to
require separate definitions anyway. The latter would be a pretty
simple addition to ethereal. Hopefully I'll get a chance to submit a
patch for it.
There's a more general problem with the hf_register_info structure in
that it's entirely monolithic, forcing you to make changes all
throughout your dissector's code any time you add a field. You
should really be able to localize all dissection of a given field,
either within a discrete section of a source file, or even within
separate source files (for large dissectors).
I think the best solution to this latter problem is probably changing
the register function to take an array of hf_register_info's. (Or,
alternatively, you could add a new function, leaving the old one
backward compatible.) This lets you create hf_register_info
structures right next to where they're used. Yes, you need to point
to them when you call the registration function, but you only need a
single pointer. You don't have to have a 300-element-long structure
sitting at the end of your file.
-P
