On Feb 20, 2014, at 8:12 AM, John Dill <John.Dill@xxxxxxxxxxxxxxxxx> wrote:
> On 19 Feb 2014, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
>> If it's deemed too-inconvenient to require that all spare
>> fields/padding/etc. be given some named field or fields, perhaps
>> we should have a
>>
>> proto_tree_add_spare(tree, tvb, offset, len);
>>
>> API, perhaps with a global preference item to indicate whether those
>> fields should be displayed in the protocol tree or not; if displayed,
>> they'll be shown as the raw hex data.
>>
>> An additional API might be
>>
>> proto_tree_add_mbz(tree, tvb, offset, len);
>>
>> which is similar, but doesn't display the value unless it's non-zero,
>> *and* adds an expert info item if it's non-zero.
>
> Those functions sound very reasonable for controlling the display of
> spare bytes, but I'm also greedy enough to want some way to kick these
> Spare and Reserved header_field_info structures out of the Filter
> Expression dialog.
In what fashion would those functions not achieve that goal?
