Ethereal-dev: RE: [Ethereal-dev] [RFC] specially mark protocol fields "generate d" byEthereal?

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Ulf Lamping" <ulf.lamping@xxxxxx>
Date: Fri, 30 Apr 2004 12:40:18 +0200
Ethereal development <ethereal-dev@xxxxxxxxxxxx> schrieb am 30.04.04 10:44:12:
> 
> |From: Ulf Lamping
> |
> |It might be even a better idea to provide this info into the 
> |hf_register_info by adding it in a "machine friendly" format, like 
> |or'ing a flag into the FT_xy fields.
> 
> I agree with you. This way an end-user may decide what to do with a given
> type of header fields (inclusive showing/hiding them and choosing how to
> render them).
> Maybe we need to specify this distinction in the PDML language too.

I've changed the PDML output some days ago, so a none visible field will be marked as such :-)
The generated flag has no representation in the current PDML spec.

> 
> Also note that fields may have the hidden flag and the generated flag on at
> the same time.

Of course this should be a flag or'ed to the "normal" FT_ field, FTF_HIDDEN and FTF_GENERATED (usually, if hidden is used, generated will also be used), so for example:

#define FTF_HIDDEN 0x8000
#define FTF_GENERATED 0x4000

> 
> |So the hf_register_info entry could look, like: FT_FRAMENUM | 
> |FT_GENERATED, or we could provide another set of field registration 
> |functions, like: proto_tree_add_uint_generated()
> 
> Here we need to be careful as today the FT_* are an enum which may be just
> one single 8-bit byte.

an enum is an int (ANSI C), and an int is an all of our platforms 32bit AFAIK, so no problem here.

> 
> We however still have some spare room in the HFILL macro to accommodate a
> bitfield without requiring us to edit all dissectors. We could even write
> HFILL for default, HFILL_HIDDEN for hidden, HFILL_GENERATED for generated
> and HFILL_GENERATED_HIDDEN for hidden generated fields, but there are
> certainly other worthwile approaches.

As described above, or'ing to the FT_ fields should be ok for the reasons described above.

> 
> |Anyone an idea of how much effort that would be?
> 
> Add the basic framework to the field registration: minimal.
> Add the field rendering changes: minimal, mainly GTK+.

As I know GTK now, both agreed.

> Review the dissectors: potentially huge, but not required for technically
> running Ethereal.

Fortunately, we can make the changes step by step.

Regards, ULFL
____________________________________________________________________
Der WEB.DE Virenschutz schuetzt Ihr Postfach vor dem Wurm Sober.A-F!
Kostenfrei fuer FreeMail Nutzer. http://f.web.de/?mc=021158