Wireshark · Wireshark-dev: Re: [Wireshark-dev] Undissected reserved fields

[Alexis La Goutte <alexis.lagoutte@xxxxxxxxx>]

Hi,

+1 with this feature !

On Sun, Mar 1, 2015 at 7:34 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:

On Mar 1, 2015, at 4:58 AM, Michal Labedzki <michal.labedzki@xxxxxxxxx> wrote:

> Personally, I always dissect reserved fields. Please do not forget
> that there are many bit-reserved fields too. This probably implies
> that we want to create filter for them (hf items), to keep the same
> look for all fields in bitfield.

The look for reserved fields should be

        Reserved

or

        000. .... .... ....: Reserved

so they don't need individual hf_items.

> I am not sure if _ws.reserved is fine in bitfield.

If it doesn't work, we should make it work.

> For other fields, I think also is good idea to create new
> filters, because purpose of reserved field is to be used in future,
> right? (in my practise... I think not...)

"Reserved" means "reserved", as in "we're reserving these bits in case we ever want to use them in the future".  When they *do* get used, we can add a field for them; even if each reserved field had its own field, we'd *still* have to change the field if the bits in question are used.

The inspiration for the add_mbz and add_reserved functions was that the person who started the thread explicitly *didn't* want the list of filterable fields filled up with extra fields for each individual reserved area.

> proto_tree_add_reserved_mbz()? (if use _ws.reserved)
> Or maybe...
> proto_tree_add_item(..., ENC_LITTLE_ENDIAN | ENC_MBZ)?  # ENC_MBZ,
> seems to be similar format like ENC_ASCII, ENC_UTF8...

It's not really an encoding - there's nothing being encoded.

It's true but i like too the idea of using  ENC_LITTLE_ENDIAN | ENC_MBZ / ENC_SPARE

Or may be add BASE on hf ? like BASE_DEC | ENC_MBZ ?

> By the way...
> Add expert info if ENC_ASCII is not ASCII? The same for UTF8.

The same for *all* string encodings in which not all octet sequences are valid.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe