> On Mon, May 21, 2001 at 09:39:48PM -0700, Guy Harris wrote:
> > Well, one problem is that it means you have to add a bunch of additional
> > fields to every entry in the "hf_register_info" array, to squelch the
> > warnings. That makes it even more of a pain to set up that array.
>
> It's 5 more values which will be "typed" via copy/paste in many (most?)
> cases anyway.
Perhaps, but it's still a pain - and, if we ever add additional fields
that are not intended to be initialized by the dissector registering the
fields (which is the case for the fields we don't currently initialize),
every dissector would have to be changed to squelch the flood of
warnings.
> > Perhaps we should define a macro to use to initialize those entries - or
> > perhaps multiple macros, for different types.
>
> Something along the line
> #define Z1 0
> #define Z2 0,0
> ...
> #define Zn 0,0,...,0 (n-times)
> ?
No, something along the lines of
#define HEADER_FIELD(name, abbrev, type, display, strings, bitmask, blurb) \
{ name, abbrev, type, display, strings, bitmask, blurb, 0, 0, 0, \
NULL, NULL }
so that you'd do
static hf_register_info hf[] = {
{ &hf_hello_sailor,
HEADER_FIELD("Hello Sailor", "hello,sailor", FT_UINT8, BASE_DEC,
NULL, 0x0, "Hello, sailor!") },
};
or perhaps multiple macros that doesn't have arguments for fields that
aren't used for particular types of objects and just fills them in with
NULL or 0 (if any).
