guy,
thanks for the explanation. it really does help.
it would be clearer if the length of the call should be 1. the mask takes care
of displaying just the single bit we are interested in. there really isn't any
relationship/dependancy with the reserved field (rest of the 14 bits).
----- Original Message -----
From: "Guy Harris" <gharris@xxxxxxxxx>
To: "Aamer Akhter" <aakhter@xxxxxxxxx>
Cc: <ethereal-dev@xxxxxxxxxxxx>
Sent: Saturday, March 16, 2002 2:34 PM
Subject: Re: [Ethereal-dev] LDP common hello param fixes
> On Fri, Mar 15, 2002 at 11:02:18PM -0500, Aamer Akhter wrote:
> > thanks guy, i got carried away with the changes. i should have checked the
> > decl of _item. i guess somebody should change the decl in README.developer
it
> > says that value follows length in the arglist.
>
> I'll fix that.
>
> > it's late friday night, so that's prob it. ;-) you still need to change
the
> > length in the last two calls (_val_target and _val_request) to 1.
>
> Change the length in the calls to 1, or change the bit count in the
> declaration of those fields to 16? It appears that those two fields are
> part of a 16-bit field, with the reserved value being the remaining 14
> bits.
>
> > why is proto_tree_add_item() favored over boolean?
>
> Because it fetches the value for you.
>
> This means that you don't have to specify the same offset in the
> "proto_tree_add_boolean()" call (or the "proto_tree_add_uint()" call, or
> the "proto_tree_add_bytes()" call, or...) *and* in the call to fetch the
> value, and you don't have the specify the same length in those two
> calls, either (whether the length is specified explicitly as a number,
> or implicitly in the name of the routine you're calling to fetch the
> value).
>
> Thus, for example, you don't have calls such as
>
> proto_tree_add_uint(tree, hf_foo, tvb, offset, 2,
> tvb_get_ntohl(offset));
>
> (yes, I have fixed erroneous calls of that sort - and changed them to
> "proto_tree_add_item()" calls:
>
> proto_tree_add_item(tree, hf_foo, tvb, offset, 2, FALSE);
>
> It also means that if "tree" is null, i.e. no protocol tree is being
> built, "proto_tree_add_item()" won't even bother fetching the value,
> which can save some time.
>
> > is there any place where boolean would be favored over item.
>
> If:
>
> 1) the value is not extracted directly from the packet data, but
> is computed from data extracted from the packet
>
> or
>
> 2) you want to use a non-standard format (note that if you just
> want to, for example, use names such as "You bet!" for "true"
> and "No way!" for "false", you can do that with
> "proto_tree_add_item()" by giving the field the right
> "true_false_string" table)
>
> or
>
> 3) you've already fetched the item into a variable and want to
> avoid having "proto_tree_add_item()" fetch it again (although
> this may not actually make a performance difference)
>
> then you would use the other "proto_tree_add" routines, such as
> "proto_tree_add_uint()", "proto_tree_add_bytes()", and so on.