Fix an erroneous example.

svn path=/trunk/; revision=5851
This commit is contained in:
Guy Harris 2002-07-10 04:24:37 +00:00
parent 7ad8ddcc46
commit caaccf5a94
1 changed files with 16 additions and 19 deletions

View File

@ -1,4 +1,4 @@
$Id: README.developer,v 1.56 2002/06/29 00:15:18 guy Exp $
$Id: README.developer,v 1.57 2002/07/10 04:24:37 guy Exp $
This file is a HOWTO for Ethereal developers. It describes how to start coding
a Ethereal protocol dissector and the use some of the important functions and
@ -139,7 +139,7 @@ code inside
is needed only if you are using the "snprintf()" function.
The "$Id: README.developer,v 1.56 2002/06/29 00:15:18 guy Exp $"
The "$Id: README.developer,v 1.57 2002/07/10 04:24:37 guy Exp $"
in the comment will be updated by CVS when the file is
checked in; it will allow the RCS "ident" command to report which
version of the file is currently checked out.
@ -149,7 +149,7 @@ version of the file is currently checked out.
* Routines for PROTONAME dissection
* Copyright 2000, YOUR_NAME <YOUR_EMAIL_ADDRESS>
*
* $Id: README.developer,v 1.56 2002/06/29 00:15:18 guy Exp $
* $Id: README.developer,v 1.57 2002/07/10 04:24:37 guy Exp $
*
* Ethereal - Network traffic analyzer
* By Gerald Combs <gerald@ethereal.com>
@ -1130,12 +1130,12 @@ and, for integral and Boolean fields, the byte order of the value; the
byte order is specified by the 'little_endian' argument, which is TRUE
if the value is little-endian and FALSE if it is big-endian.
Now that the proto_tree has detailed information about bitfield fields,
you can use proto_tree_add_item() with no extra processing to add bitfield
values to your tree. Here's an example. Take the Format Identifer (FID)
field in the Transmission Header (TH) portion of the SNA protocol. The
FID is the high nibble of the first byte of the TH. The FID would be
registered like this:
Now that definitions of fields have detailed information about bitfield
fields, you can use proto_tree_add_item() with no extra processing to
add bitfield values to your tree. Here's an example. Take the Format
Identifer (FID) field in the Transmission Header (TH) portion of the SNA
protocol. The FID is the high nibble of the first byte of the TH. The
FID would be registered like this:
name = "Format Identifer"
abbrev = "sna.th.fid"
@ -1149,17 +1149,14 @@ against the parent field, the first byte of the TH.
The code to add the FID to the tree would be;
guint8 th_0 = tvb_get_guint8(tvb, offset);
proto_tree_add_item(bf_tree, hf_sna_th_fid, tvb, offset, 1, th_0);
proto_tree_add_item(bf_tree, hf_sna_th_fid, tvb, offset, 1, TRUE);
Note: we do not do *any* manipulation of th_0 in order to get the FID value.
We just pass it to proto_tree_add_item(). The proto_tree already has
the information about bitmasking and bitshifting, so it does the work
of masking and shifting for us! This also means that you no longer
have to crate value_string structs with the values bitshifted. The
value_string for FID looks like this, even though the FID value is
actually contained in the high nibble. (You'd expect the values to be
0x0, 0x10, 0x20, etc.)
The definition of the field already has the information about bitmasking
and bitshifting, so it does the work of masking and shifting for us!
This also means that you no longer have to crate value_string structs
with the values bitshifted. The value_string for FID looks like this,
even though the FID value is actually contained in the high nibble.
(You'd expect the values to be 0x0, 0x10, 0x20, etc.)
/* Format Identifier */
static const value_string sna_th_fid_vals[] = {