From caaccf5a945752999dad0db86e8c178d5f9fe1be Mon Sep 17 00:00:00 2001 From: Guy Harris Date: Wed, 10 Jul 2002 04:24:37 +0000 Subject: [PATCH] Fix an erroneous example. svn path=/trunk/; revision=5851 --- doc/README.developer | 35 ++++++++++++++++------------------- 1 file changed, 16 insertions(+), 19 deletions(-) diff --git a/doc/README.developer b/doc/README.developer index 31600359cc..90cd85e082 100644 --- a/doc/README.developer +++ b/doc/README.developer @@ -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 * - * $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 @@ -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[] = {