Re: Undissected reserved fields

[Alexis La Goutte <alexis.lagoutte () gmail com>]

On Sun, Mar 1, 2015 at 7:34 PM, Guy Harris <guy () alum mit edu> wrote:

> On Mar 1, 2015, at 4:58 AM, Michal Labedzki <michal.labedzki () tieto com>
> 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.
>
> > 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 () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe