On Feb 19, 2014, at 4:03 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
> It was at one point (long ago before wireshark had filtering) the
> default API, so it is in a lot of old code. People often use it by
> mistake when they *want* filterable items. It's also not quite as
> abstract, since the data must be fetched separately, and the offset
> must be specified twice.
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.
