On Feb 19, 2014, at 4:03 PM, Evan Huus <eapa...@gmail.com> 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.
___________________________________________________________________________
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
