On Sat, Jul 08, 2000 at 12:58:10AM -0700, Guy Harris wrote:
> On Fri, Jul 07, 2000 at 08:01:57AM -0500, Gilbert Ramirez wrote:
> > 2) Your example of having proto_tree_add_ipv4() accept a pointer.
> > The dissector looks like this:
> >
> > proto_tree_add_ipv4(..., tvb_get_ptr(.., 4))
> >
> > It still assumes a certain byte order in the packet, which is good,
> > since proto_tree_add_item() will still work for FT_IPv4 fields.
>
> Note that in some cases the pointer handed to "proto_tree_add_ipv4()"
> will have to be a pointer to a local variable on the stack - the ONC RPC
> "bootparams" protocol appears to have, as one of the fields, an IP
> address represented as four XDR-format integral values, one per octet of
> the address, which means four 32-bit (and apparently signed...) integral
> quantities.
>
> Are there any situations where one would use "proto_tree_add_ipv4()"
> with a pointer argument where one couldn't just use
> "proto_tree_add_item()" (other than code that hasn't yet been converted
> to use tvbuffs, as "proto_tree_add_item()" extracts the value of the
> field with tvbuff calls)?
Good point. None that I can think of. So, we stick to
proto_tree_add_item() when extracting from the tvbuff directly, and the
proto_tree_add_<type>() calls take a C type representing that FT_* type.
An IPv4 address fits in single C type, but an IPv6 address doesn't,
so that's the reason proto_tree_add_ipv6() takes a pointer. I think if
we be sure to describe it like that, it's a model that won't be confusing.
--gilbert
