On Mon, Oct 09, 2000 at 11:35:24AM +0900, Richard Sharpe wrote:
> I was tripping over problems with proto_tree_add_bytes_hidden that takes a
> pointer to a string (start_ptr), which seems to allow you to add a string
> to the protocol tree that is different to the bytes in the frame buffer
> that will be highlighted when you select things.
>
> Is this correct?
"Correct" as in "is it true that it allows you to do that"?
Yes, it does allow you to do that - as does "proto_tree_add_bytes()", and
as do "proto_tree_add_string()" and "proto_tree_add_string_hidden()".
That's a side-effect of the fact that they don't take, as an argument, a
pointer to the beginning of the packet buffer, and compute the pointer
to the item from that pointer and the starting-offset argument, so you
have to pass them a pointer to the beginning of the item.
Once all dissectors are tvbuffified, we could have them use the tvbuff
argument and starting offset, and not have to take an argument that's a
pointer to the beginning of the item.
For strings, there *might* be cases where you don't want the string in
the protocol tree to exactly match the raw data in the packet, just as
there are some cases where "proto_tree_add_uint()", for example, is
handed a value other than the raw value from the packet (the header
length field in an IP packet is a count of 4-byte words, but the value
of that field in the protocol tree is a count of bytes).
I'm not sure that'd be useful for an array of bytes, however.
However, if your dissector is tvbuffified *and* the field is registered,
you can use "proto_tree_add_item()", which extracts the value from the
packet data using the tvbuff, offset, and length arguments.