On 02/21/14 14:42, Guy Harris wrote:
On Feb 21, 2014, at 8:15 AM, "John Dill" <John.Dill@xxxxxxxxxxxxxxxxx> wrote:
From the topic discussion, I got the impression that not
putting hf_register_info entries for Spare or Reserved fields
was considered bad practice.
Some might consider it bad practice; I don't.
I'm one who has said it is bad practice. But... (more below)
The only advantage to having it be a named field would be to be able to filter for a specific value for the field, or to check whether it's non-zero.
I'm not sure there's any point in filtering for specific values.
There might be some use for checking for non-zero values *if* the spare bits are supposed to be zero; that's why I suggested proto_tree_add_mbz(), if, for a given collection of spare bits, those bits Must Be Zero.
That's true: in fact the only real use case I've had for it is filtering
"xxx.yyy.spare != 0" because that helps me prove that implementation A
is violating the law (which says the bits must be 0).
Personally I'd probably still err on the side of "add a [filterable]
field for spare bytes" because I like to filter for them but there's no
reason I couldn't do that and others could use these APIs.
