Wireshark · Ethereal-dev: [Ethereal-dev] [RFC 2nd try] specially mark protocol fields "generated" by Ethereal?

[Ulf Lamping <ulf.lamping@xxxxxx>]

Hi List!

After my first proposal of marking special protocol fields as 
"generated", a lot of responses to this topic comes in.

Especially Ronnies response reminded me, that my first proposal was too 
inflexible of handling special cases, so I would like to propose a 
different approach now.

Instead of putting this additional  field information into the 
hf_register_info data at protocol registry (which is too inflexible), 
this info should be stored in the field_info while adding the the items 
to the proto_tree, just replacing the current visible field (currently 
used as a single flag only :-).

I would think of using a value holding several flags. The following 
"rendering specific" flags comes to my mind:

#define FI_HIDDEN         0x0001
#define FI_GENERATED        0x0002      /* still need a good name for 
this */

This flag field could also keep other field specific information, like a 
more general way of marking bad packets (e.g. when a checksum failed). 
When I remember it correct, this "expert functionality" was dicussed on 
the list weeks/months already before. But please *don't* start a 
discussion on this error reporting topic right now, and let's focus on 
the correct mechanisms to handover this flag to the display output.

So I've added the following macros to the proto.h:

#define PROTO_ITEM_SET_HIDDEN(proto_item)       
FI_SET_FLAG(proto_item->finfo, FI_HIDDEN)
#define PROTO_ITEM_SET_GENERATED(proto_item)    
FI_SET_FLAG(proto_item->finfo, FI_GENERATED)

So instead of adding these flags as a parameter to the proto_add_xy_item 
(and add new functions for every FT_), this new functions should be 
called, after the normal proto_tree_add_xy functions returned.

This don't break anything in all the existing dissectors (as all the API 
calls are unchanged), and we can bring the old 
"proto_tree_add_xy_hidden" calls to this new API design step by step.

I've checked in the changes for some of the values in the TCP dissector 
(see: "SEQ/ACK Analysis"), so you might want have a look there.

Regards, ULFL