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.
> 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.
