Hi, +1 with this feature !
On Sun, Mar 1, 2015 at 7:34 PM, Guy Harris <g...@alum.mit.edu> wrote: > > On Mar 1, 2015, at 4:58 AM, Michal Labedzki <michal.labed...@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. > 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@wireshark.org> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@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-requ...@wireshark.org?subject=unsubscribe
