forked from osmocom/wireshark
Fix an erroneous example.
svn path=/trunk/; revision=5851
This commit is contained in:
parent
7ad8ddcc46
commit
caaccf5a94
|
@ -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[] = {
|
||||
|
|
Loading…
Reference in New Issue