1999-07-07 22:52:57 +00:00
|
|
|
/* proto.h
|
|
|
|
* Definitions for protocol display
|
|
|
|
*
|
2004-07-18 00:24:25 +00:00
|
|
|
* $Id$
|
1999-07-07 22:52:57 +00:00
|
|
|
*
|
|
|
|
* Ethereal - Network traffic analyzer
|
Enable "Match Selected" only if there's a field selected *and* we can do
a "Match Selected" on it - we can't do a "Match Selected" if the field
has no value (e.g., FT_NULL) and has a length of 0.
If we unselect the current packet, we don't have a protocol tree, so we
don't have a currently selected field - clear the "Match Selected" menu
item and the display in the status line of information about the
currently selected field.
Move the low-level statusbar manipulation into "gtk/main.c", in routines
whose API doesn't expose anything GTK+-ish.
"close_cap_file()" calls one of those routines to clear out the status
bar, so it doesn't need to take a pointer to the statusbar widget as an
argument.
"clear_tree_and_hex_views()" is purely a display-manipulating routine;
move it to "gtk/proto_draw.c".
Extract from "tree_view_unselect_row_cb()" an "unselect_field()" routine
to do all the work that needs to be done if the currently selected
protocol tree row is unselected, and call it if the currently selected
packet list row is unselected (if it's unselected, there *is* no
protocol tree, so no row can be selected), as well as from
"tree_view_unselect_row_cb()".
Before pushing a new field-description message onto the statusbar, pop
the old one off.
Get rid of an unused variable (set, but not used).
svn path=/trunk/; revision=3513
2001-06-05 07:39:31 +00:00
|
|
|
* By Gerald Combs <gerald@ethereal.com>
|
1999-07-07 22:52:57 +00:00
|
|
|
* Copyright 1998 Gerald Combs
|
2002-08-28 20:41:00 +00:00
|
|
|
*
|
1999-07-07 22:52:57 +00:00
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
2002-08-28 20:41:00 +00:00
|
|
|
*
|
1999-07-07 22:52:57 +00:00
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
2002-08-28 20:41:00 +00:00
|
|
|
*
|
1999-07-07 22:52:57 +00:00
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|
|
|
*/
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
|
|
|
|
/*! @file proto.h
|
|
|
|
The protocol tree related functions.<BR>
|
|
|
|
A protocol tree will hold all necessary data to display the whole dissected packet.
|
|
|
|
Creating a protocol tree is done in a two stage process:
|
|
|
|
A static part at program startup, and a dynamic part when the dissection with the real packet data is done.<BR>
|
|
|
|
The "static" information is provided by creating a hf_register_info hf[] array, and register it using the
|
|
|
|
proto_register_field_array() function. This is usually done at dissector registering.<BR>
|
|
|
|
The "dynamic" information is added to the protocol tree by calling one of the proto_tree_add_...() functions,
|
|
|
|
e.g. proto_tree_add_bytes().
|
|
|
|
*/
|
|
|
|
|
1999-07-07 22:52:57 +00:00
|
|
|
#ifndef __PROTO_H__
|
|
|
|
#define __PROTO_H__
|
|
|
|
|
2000-08-10 16:04:33 +00:00
|
|
|
#ifdef HAVE_STDARG_H
|
|
|
|
# include <stdarg.h>
|
|
|
|
#else
|
|
|
|
# include <varargs.h>
|
|
|
|
#endif
|
|
|
|
|
2001-12-07 03:39:26 +00:00
|
|
|
#include <glib.h>
|
|
|
|
|
1999-11-15 06:32:38 +00:00
|
|
|
#include "ipv4.h"
|
2001-09-14 07:10:13 +00:00
|
|
|
#include "nstime.h"
|
2000-05-11 08:18:09 +00:00
|
|
|
#include "tvbuff.h"
|
2001-02-01 20:21:25 +00:00
|
|
|
#include "ftypes/ftypes.h"
|
2000-05-11 08:18:09 +00:00
|
|
|
|
2004-07-29 00:11:14 +00:00
|
|
|
/** The header-field index for the special text pseudo-field. Exported by libethereal.dll */
|
|
|
|
ETH_VAR_IMPORT int hf_text_only;
|
2003-12-06 06:09:13 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** the maximum length of a protocol field string representation */
|
1999-07-07 22:52:57 +00:00
|
|
|
#define ITEM_LABEL_LENGTH 240
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
struct _value_string;
|
|
|
|
|
|
|
|
/** Make a const value_string[] look like a _value_string pointer, used to set header_field_info.strings */
|
2002-11-28 01:46:14 +00:00
|
|
|
#define VALS(x) (const struct _value_string*)(x)
|
1999-07-07 22:52:57 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Make a const true_false_string[] look like a _true_false_string pointer, used to set header_field_info.strings */
|
2002-11-28 01:46:14 +00:00
|
|
|
#define TFS(x) (const struct true_false_string*)(x)
|
1999-07-07 22:52:57 +00:00
|
|
|
|
2004-05-01 20:15:56 +00:00
|
|
|
struct _protocol;
|
2004-05-10 23:13:55 +00:00
|
|
|
|
|
|
|
/** Structure for information about a protocol */
|
2003-11-16 23:17:27 +00:00
|
|
|
typedef struct _protocol protocol_t;
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** check protocol activation
|
|
|
|
* @todo this macro looks like a hack */
|
2001-11-26 05:13:14 +00:00
|
|
|
#define CHECK_DISPLAY_AS_X(x_handle,index, tvb, pinfo, tree) { \
|
2003-11-16 23:17:27 +00:00
|
|
|
if (!proto_is_protocol_enabled(find_protocol_by_id(index))) { \
|
|
|
|
call_dissector(x_handle,tvb, pinfo, tree); \
|
|
|
|
return; \
|
|
|
|
} \
|
2001-11-26 05:13:14 +00:00
|
|
|
}
|
|
|
|
|
1999-10-12 06:21:15 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** GNUC has the ability to check format strings that follow the syntax used in printf and others.
|
|
|
|
Hide the differences between different compilers in this GNUC_FORMAT_CHECK macro.
|
|
|
|
@param archetype one of: printf, scanf, strftime or strfmon
|
|
|
|
@param string_index specifies which argument is the format string argument (starting from 1)
|
|
|
|
@param first_to_check is the number of the first argument to check against the format string
|
|
|
|
@todo as this check is also done at some other places too, move this macro to a more central place? */
|
|
|
|
#if __GNUC__ >= 2
|
|
|
|
#define GNUC_FORMAT_CHECK(archetype, string_index, first_to_check) __attribute__((format (archetype, string_index, first_to_check)))
|
|
|
|
#else
|
|
|
|
#define GNUC_FORMAT_CHECK(archetype, string_index, first_to_check)
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
|
|
/** radix for decimal values, used in header_field_info.display */
|
|
|
|
typedef enum {
|
|
|
|
BASE_NONE, /**< none */
|
|
|
|
BASE_DEC, /**< decimal */
|
|
|
|
BASE_HEX, /**< hexadecimal */
|
|
|
|
BASE_OCT /**< octal */
|
|
|
|
} base_display_e;
|
|
|
|
|
|
|
|
/** information describing a header field */
|
2001-02-01 20:21:25 +00:00
|
|
|
typedef struct _header_field_info header_field_info;
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** information describing a header field */
|
2001-02-01 20:21:25 +00:00
|
|
|
struct _header_field_info {
|
|
|
|
/* ---------- set by dissector --------- */
|
2004-05-10 23:13:55 +00:00
|
|
|
char *name; /**< full name of this field */
|
|
|
|
char *abbrev; /**< abbreviated name of this field */
|
|
|
|
enum ftenum type; /**< field type, one of FT_ (from ftypes.h) */
|
|
|
|
int display; /**< one of BASE_, or number of field bits for FT_BOOLEAN */
|
|
|
|
const void *strings; /**< _value_string (or true_false_string for FT_BOOLEAN), typically converted by VALS() or TFS() */
|
|
|
|
guint32 bitmask; /**< FT_BOOLEAN only: bitmask of interesting bits */
|
|
|
|
char *blurb; /**< Brief description of field. */
|
1999-10-12 06:21:15 +00:00
|
|
|
|
2004-05-09 09:26:31 +00:00
|
|
|
/* ------- set by proto routines (prefilled by HFILL macro, see below) ------ */
|
2004-05-10 23:13:55 +00:00
|
|
|
int id; /**< Field ID */
|
|
|
|
int parent; /**< parent protocol tree */
|
|
|
|
int bitshift; /**< bits to shift (FT_BOOLEAN only) */
|
|
|
|
header_field_info *same_name_next; /**< Link to next hfinfo with same abbrev*/
|
|
|
|
header_field_info *same_name_prev; /**< Link to previous hfinfo with same abbrev*/
|
2001-02-01 20:21:25 +00:00
|
|
|
};
|
1999-07-07 22:52:57 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/**
|
2001-06-18 02:18:27 +00:00
|
|
|
* HFILL initializes all the "set by proto routines" fields in a
|
2004-05-10 23:13:55 +00:00
|
|
|
* _header_field_info. If new fields are added or removed, it should
|
2001-06-18 02:18:27 +00:00
|
|
|
* be changed as necessary.
|
|
|
|
*/
|
|
|
|
#define HFILL 0, 0, 0, NULL, NULL
|
2000-04-03 09:24:12 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Used when registering many fields at once, using proto_register_field_array() */
|
1999-07-07 22:52:57 +00:00
|
|
|
typedef struct hf_register_info {
|
2004-05-10 23:13:55 +00:00
|
|
|
int *p_id; /**< written to by register() function */
|
|
|
|
header_field_info hfinfo; /**< the field info to be registered */
|
1999-07-07 22:52:57 +00:00
|
|
|
} hf_register_info;
|
|
|
|
|
2003-11-25 14:07:45 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
|
|
|
|
|
|
|
|
/** string representation, if one of the proto_tree_add_..._format() functions used */
|
2003-11-25 14:07:45 +00:00
|
|
|
typedef struct _item_label_t {
|
2003-11-26 12:22:22 +00:00
|
|
|
char representation[ITEM_LABEL_LENGTH];
|
2003-11-25 14:07:45 +00:00
|
|
|
} item_label_t;
|
|
|
|
|
2004-05-01 15:15:08 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Contains the field information for the proto_item. */
|
1999-07-07 22:52:57 +00:00
|
|
|
typedef struct field_info {
|
2004-05-10 23:13:55 +00:00
|
|
|
header_field_info *hfinfo; /**< pointer to registered field information */
|
|
|
|
gint start; /**< current start of data in field_info.ds_tvb */
|
|
|
|
gint length; /**< current data length of item in field_info.ds_tvb */
|
|
|
|
gint tree_type; /**< ETT_ */
|
|
|
|
item_label_t *rep; /**< string for GUI tree */
|
|
|
|
int flags; /**< one of FI_HIDDEN, ... */
|
|
|
|
tvbuff_t *ds_tvb; /**< data source tvbuff */
|
2003-12-02 21:15:49 +00:00
|
|
|
fvalue_t value;
|
1999-07-07 22:52:57 +00:00
|
|
|
} field_info;
|
|
|
|
|
2004-05-01 15:15:08 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** The protocol field should not be shown in the tree (it's used for filtering only),
|
|
|
|
* used in field_info.flags. */
|
2004-05-01 15:15:08 +00:00
|
|
|
#define FI_HIDDEN 0x0001
|
2004-05-10 23:13:55 +00:00
|
|
|
/** The protocol field should be displayed as "generated by Ethereal",
|
|
|
|
* used in field_info.flags. */
|
2004-05-01 15:15:08 +00:00
|
|
|
#define FI_GENERATED 0x0002
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** convenience macro to get field_info.flags */
|
2004-05-01 15:15:08 +00:00
|
|
|
#define FI_GET_FLAG(fi, flag) (fi->flags & flag)
|
2004-05-10 23:13:55 +00:00
|
|
|
/** convenience macro to set field_info.flags */
|
2004-05-01 15:15:08 +00:00
|
|
|
#define FI_SET_FLAG(fi, flag) (fi->flags = fi->flags | flag)
|
|
|
|
|
|
|
|
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** One of these exists for the entire protocol tree. Each proto_node
|
2001-12-18 19:09:08 +00:00
|
|
|
* in the protocol tree points to the same copy. */
|
|
|
|
typedef struct {
|
|
|
|
GHashTable *interesting_hfids;
|
|
|
|
gboolean visible;
|
|
|
|
} tree_data_t;
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Each proto_tree, proto_item is one of these. */
|
2003-11-26 12:22:22 +00:00
|
|
|
typedef struct _proto_node {
|
2003-12-04 10:59:34 +00:00
|
|
|
struct _proto_node *first_child;
|
|
|
|
struct _proto_node *last_child;
|
|
|
|
struct _proto_node *next;
|
2003-12-04 19:53:54 +00:00
|
|
|
struct _proto_node *parent;
|
2003-11-26 12:22:22 +00:00
|
|
|
field_info *finfo;
|
|
|
|
tree_data_t *tree_data;
|
2001-12-18 19:09:08 +00:00
|
|
|
} proto_node;
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** A protocol tree element. */
|
2003-12-04 10:59:34 +00:00
|
|
|
typedef proto_node proto_tree;
|
2004-05-10 23:13:55 +00:00
|
|
|
/** A protocol item element. */
|
2003-12-04 10:59:34 +00:00
|
|
|
typedef proto_node proto_item;
|
2001-12-18 19:09:08 +00:00
|
|
|
|
2004-05-01 15:15:08 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** is this protocol field hidden from the protocol tree display (used for filtering only)? */
|
2004-05-01 20:15:56 +00:00
|
|
|
#define PROTO_ITEM_IS_HIDDEN(proto_item) \
|
|
|
|
((proto_item) ? FI_GET_FLAG(proto_item->finfo, FI_HIDDEN) : 0)
|
2004-05-10 23:13:55 +00:00
|
|
|
/** mark this protocol field to be hidden from the protocol tree display (used for filtering only) */
|
2004-05-01 20:15:56 +00:00
|
|
|
#define PROTO_ITEM_SET_HIDDEN(proto_item) \
|
|
|
|
((proto_item) ? FI_SET_FLAG(proto_item->finfo, FI_HIDDEN) : 0)
|
2004-05-10 23:13:55 +00:00
|
|
|
/** is this protocol field generated by Ethereal (and not read from the packet data)? */
|
2004-05-01 20:15:56 +00:00
|
|
|
#define PROTO_ITEM_IS_GENERATED(proto_item) \
|
|
|
|
((proto_item) ? FI_GET_FLAG(proto_item->finfo, FI_GENERATED) : 0)
|
2004-05-10 23:13:55 +00:00
|
|
|
/** mark this protocol field as generated by Ethereal (and not read from the packet data) */
|
2004-05-01 20:15:56 +00:00
|
|
|
#define PROTO_ITEM_SET_GENERATED(proto_item) \
|
|
|
|
((proto_item) ? FI_SET_FLAG(proto_item->finfo, FI_GENERATED) : 0)
|
2004-05-01 15:15:08 +00:00
|
|
|
|
|
|
|
|
2003-12-04 10:59:34 +00:00
|
|
|
typedef void (*proto_tree_foreach_func)(proto_node *, gpointer);
|
|
|
|
|
|
|
|
extern void proto_tree_children_foreach(proto_tree *tree,
|
|
|
|
proto_tree_foreach_func func, gpointer data);
|
2001-12-18 19:09:08 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Retrieve the field_info from a proto_item */
|
2004-05-10 14:02:17 +00:00
|
|
|
#define PITEM_FINFO(proto_item) ((proto_item)->finfo)
|
2001-12-18 19:09:08 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Retrieve the tree_data_t from a proto_tree */
|
2004-05-10 14:02:17 +00:00
|
|
|
#define PTREE_DATA(proto_tree) ((proto_tree)->tree_data)
|
1999-07-07 22:52:57 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
|
|
|
|
|
|
|
|
/** Sets up memory used by proto routines. Called at program startup */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern void proto_init(const char *plugin_dir,
|
|
|
|
void (register_all_protocols)(void), void (register_all_handoffs)(void));
|
1999-08-26 06:20:50 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Frees memory used by proto routines. Called at program shutdown */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern void proto_cleanup(void);
|
1999-08-26 06:20:50 +00:00
|
|
|
|
2004-05-01 15:15:08 +00:00
|
|
|
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Create a subtree under an existing item.
|
|
|
|
@param ti the parent item of the new subtree
|
|
|
|
@param idx one of the ett_ array elements registered with proto_register_subtree_array()
|
|
|
|
@return the new subtree */
|
2004-05-01 15:15:08 +00:00
|
|
|
extern proto_tree* proto_item_add_subtree(proto_item *ti, gint idx);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Get an existing subtree under an item.
|
|
|
|
@param ti the parent item of the subtree
|
|
|
|
@return the subtree or NULL */
|
2004-05-01 15:15:08 +00:00
|
|
|
extern proto_tree* proto_item_get_subtree(proto_item *ti);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Get the parent of a subtree item.
|
|
|
|
@param ti the child item in the subtree
|
|
|
|
@return parent item or NULL */
|
2004-05-01 15:15:08 +00:00
|
|
|
extern proto_item* proto_item_get_parent(proto_item *ti);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Get Nth generation parent item.
|
|
|
|
@param ti the child item in the subtree
|
|
|
|
@param gen the generation to get (using 1 here is the same as using proto_item_get_parent())
|
|
|
|
@return parent item */
|
2004-05-01 15:15:08 +00:00
|
|
|
extern proto_item* proto_item_get_parent_nth(proto_item *ti, int gen);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Replace text of item after it already has been created.
|
|
|
|
@param ti the item to set the text
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern void proto_item_set_text(proto_item *ti, const char *format, ...)
|
2004-05-10 23:13:55 +00:00
|
|
|
GNUC_FORMAT_CHECK(printf, 2,3);
|
2000-01-22 04:59:55 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Append to text of item after it has already been created.
|
|
|
|
@param ti the item to append the text to
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern void proto_item_append_text(proto_item *ti, const char *format, ...)
|
2004-05-10 23:13:55 +00:00
|
|
|
GNUC_FORMAT_CHECK(printf, 2,3);
|
2001-08-29 00:51:10 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Set proto_item's length inside tvb, after it has already been created.
|
|
|
|
@param ti the item to set the length
|
|
|
|
@param length the new length ot the item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern void proto_item_set_len(proto_item *ti, gint length);
|
1999-10-12 06:21:15 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/**
|
2003-04-29 21:27:19 +00:00
|
|
|
* Sets the length of the item based on its start and on the specified
|
|
|
|
* offset, which is the offset past the end of the item; as the start
|
|
|
|
* in the item is relative to the beginning of the data source tvbuff,
|
2004-05-10 23:13:55 +00:00
|
|
|
* we need to pass in a tvbuff.
|
|
|
|
@param ti the item to set the length
|
|
|
|
@param tvb end is relative to this tvbuff
|
|
|
|
@param end this end offset is relative to the beginning of tvb
|
|
|
|
@todo make usage clearer, I don't understand it!
|
2003-04-29 21:27:19 +00:00
|
|
|
*/
|
2004-05-10 23:13:55 +00:00
|
|
|
extern void proto_item_set_end(proto_item *ti, tvbuff_t *tvb, gint end);
|
2003-04-29 21:27:19 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Get length of a proto_item. Useful after using proto_tree_add_item()
|
|
|
|
* to add a variable-length field (e.g., FT_NSTRING_UINT8).
|
|
|
|
@param ti the item to get the length from
|
|
|
|
@return the current length */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern int proto_item_get_len(proto_item *ti);
|
2000-07-27 06:41:59 +00:00
|
|
|
|
2004-05-01 15:15:08 +00:00
|
|
|
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Creates a new proto_tree root.
|
|
|
|
@return the new tree root */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_tree* proto_tree_create_root(void);
|
1999-10-12 06:21:15 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Clear memory for entry proto_tree. Clears proto_tree struct also.
|
|
|
|
@param tree the tree to free */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern void proto_tree_free(proto_tree *tree);
|
1999-10-12 06:21:15 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Set the tree visible or invisible.
|
|
|
|
Is the parsing being done for a visible proto_tree or an invisible one?
|
|
|
|
By setting this correctly, the proto_tree creation is sped up by not
|
|
|
|
having to call vsnprintf and copy strings around.
|
|
|
|
@param tree the tree to be set
|
|
|
|
@param visible ... or not */
|
2004-05-01 15:15:08 +00:00
|
|
|
extern void
|
|
|
|
proto_tree_set_visible(proto_tree *tree, gboolean visible);
|
2004-03-25 23:55:21 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Mark a field/protocol ID as "interesting".
|
|
|
|
@param tree the tree to be set
|
|
|
|
@param hfid the interesting field id
|
|
|
|
@todo what *does* interesting mean? */
|
2004-05-01 15:15:08 +00:00
|
|
|
extern void
|
|
|
|
proto_tree_prime_hfid(proto_tree *tree, int hfid);
|
2004-03-25 23:55:21 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Get a parent item of a subtree.
|
|
|
|
@param tree the tree to get the parent from
|
|
|
|
@return parent item */
|
2004-03-25 09:18:03 +00:00
|
|
|
extern proto_item* proto_tree_get_parent(proto_tree *tree);
|
|
|
|
|
1999-07-07 22:52:57 +00:00
|
|
|
|
1999-11-16 11:44:20 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add an item to a proto_tree, using the text label registered to that item.
|
|
|
|
The item is extracted from the tvbuff handed to it.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param little_endian big or little endian byte representation
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_item(proto_tree *tree, int hfindex, tvbuff_t *tvb,
|
|
|
|
gint start, gint length, gboolean little_endian);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a hidden item to a proto_tree.
|
|
|
|
@deprecated use proto_tree_add_item() and a subsequent call to PROTO_ITEM_SET_HIDDEN() instead */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_item_hidden(proto_tree *tree, int hfindex, tvbuff_t *tvb,
|
|
|
|
gint start, gint length, gboolean little_endian);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a text-only node to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters
|
|
|
|
@return the newly created item */
|
|
|
|
extern proto_item *
|
|
|
|
proto_tree_add_text(proto_tree *tree, tvbuff_t *tvb, gint start, gint length, const char *format,
|
|
|
|
...) GNUC_FORMAT_CHECK(printf,5,6);
|
|
|
|
|
|
|
|
/** Add a text-only node to a proto_tree using a variable argument list.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param format printf like format string
|
|
|
|
@param ap variable argument list
|
|
|
|
@return the newly created item */
|
|
|
|
extern proto_item *
|
|
|
|
proto_tree_add_text_valist(proto_tree *tree, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, const char *format, va_list ap);
|
|
|
|
|
|
|
|
|
|
|
|
/** Add a FT_NONE field to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2001-02-01 20:21:25 +00:00
|
|
|
proto_tree_add_none_format(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
2004-05-10 08:29:18 +00:00
|
|
|
gint length, const char *format, ...) GNUC_FORMAT_CHECK(printf,6,7);
|
2001-02-01 20:21:25 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a FT_PROTOCOL to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-11 08:18:09 +00:00
|
|
|
proto_tree_add_protocol_format(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
2004-05-10 14:02:17 +00:00
|
|
|
gint length, const char *format, ...) GNUC_FORMAT_CHECK(printf,6,7);
|
1999-07-07 22:52:57 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/** Add a FT_BYTES to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param start_ptr pointer to the data to display
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_bytes(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, const guint8* start_ptr);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a hidden FT_BYTES to a proto_tree.
|
|
|
|
@deprecated use proto_tree_add_bytes() and a subsequent call to PROTO_ITEM_SET_HIDDEN() instead */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_bytes_hidden(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, const guint8* start_ptr);
|
2000-03-12 04:48:32 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a formatted FT_BYTES to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param start_ptr pointer to the data to display
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-11 08:18:09 +00:00
|
|
|
proto_tree_add_bytes_format(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
2004-05-10 14:02:17 +00:00
|
|
|
gint length, const guint8* start_ptr, const char *format, ...) GNUC_FORMAT_CHECK(printf,7,8);
|
2000-01-22 04:59:55 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a FT_ABSOLUTE_TIME or FT_RELATIVE_TIME to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value_ptr pointer to the data to display
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_time(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
2001-09-14 07:10:13 +00:00
|
|
|
gint length, nstime_t* value_ptr);
|
2000-05-31 05:09:07 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a hidden FT_ABSOLUTE_TIME or FT_RELATIVE_TIME to a proto_tree.
|
|
|
|
@deprecated use proto_tree_add_time() and a subsequent call to PROTO_ITEM_SET_HIDDEN() instead */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_time_hidden(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
2001-09-14 07:10:13 +00:00
|
|
|
gint length, nstime_t* value_ptr);
|
2000-05-31 05:09:07 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a formatted FT_ABSOLUTE_TIME or FT_RELATIVE_TIME to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value_ptr pointer to the data to display
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-11 08:18:09 +00:00
|
|
|
proto_tree_add_time_format(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
2004-05-10 14:02:17 +00:00
|
|
|
gint length, nstime_t* value_ptr, const char *format, ...) GNUC_FORMAT_CHECK(printf,7,8);
|
2000-03-12 04:48:32 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a FT_IPXNET to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_ipxnet(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, guint32 value);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a hidden FT_IPXNET to a proto_tree.
|
|
|
|
@deprecated use proto_tree_add_ipxnet() and a subsequent call to PROTO_ITEM_SET_HIDDEN() instead */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_ipxnet_hidden(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, guint32 value);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a formatted FT_IPXNET to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-11 08:18:09 +00:00
|
|
|
proto_tree_add_ipxnet_format(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
2004-05-10 14:02:17 +00:00
|
|
|
gint length, guint32 value, const char *format, ...) GNUC_FORMAT_CHECK(printf,7,8);
|
2000-03-12 04:48:32 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a FT_IPv4 to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_ipv4(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, guint32 value);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a hidden FT_IPv4 to a proto_tree.
|
|
|
|
@deprecated use proto_tree_add_ipv4() and a subsequent call to PROTO_ITEM_SET_HIDDEN() instead */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_ipv4_hidden(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, guint32 value);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a formatted FT_IPv4 to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-11 08:18:09 +00:00
|
|
|
proto_tree_add_ipv4_format(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
2004-05-10 14:02:17 +00:00
|
|
|
gint length, guint32 value, const char *format, ...) GNUC_FORMAT_CHECK(printf,7,8);
|
2000-03-12 04:48:32 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a FT_IPv6 to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value_ptr data to display
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_ipv6(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, const guint8* value_ptr);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a hidden FT_IPv6 to a proto_tree.
|
|
|
|
@deprecated use proto_tree_add_ipv6() and a subsequent call to PROTO_ITEM_SET_HIDDEN() instead */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_ipv6_hidden(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, const guint8* value_ptr);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a formatted FT_IPv6 to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value_ptr data to display
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-11 08:18:09 +00:00
|
|
|
proto_tree_add_ipv6_format(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
2004-05-10 14:02:17 +00:00
|
|
|
gint length, const guint8* value_ptr, const char *format, ...) GNUC_FORMAT_CHECK(printf,7,8);
|
2000-03-12 04:48:32 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a FT_ETHER to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_ether(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, const guint8* value);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a hidden FT_ETHER to a proto_tree.
|
|
|
|
@deprecated use proto_tree_add_ether() and a subsequent call to PROTO_ITEM_SET_HIDDEN() instead */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_ether_hidden(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, const guint8* value);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a formatted FT_ETHER to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-11 08:18:09 +00:00
|
|
|
proto_tree_add_ether_format(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
2004-05-10 14:02:17 +00:00
|
|
|
gint length, const guint8* value, const char *format, ...) GNUC_FORMAT_CHECK(printf,7,8);
|
2000-03-12 04:48:32 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a FT_STRING to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_string(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, const char* value);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a hidden FT_STRING to a proto_tree.
|
|
|
|
@deprecated use proto_tree_add_string() and a subsequent call to PROTO_ITEM_SET_HIDDEN() instead */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_string_hidden(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, const char* value);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a formatted FT_STRING to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-11 08:18:09 +00:00
|
|
|
proto_tree_add_string_format(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
2004-05-10 14:02:17 +00:00
|
|
|
gint length, const char* value, const char *format, ...) GNUC_FORMAT_CHECK(printf,7,8);
|
2000-03-12 04:48:32 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a FT_BOOLEAN to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_boolean(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, guint32 value);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a hidden FT_BOOLEAN to a proto_tree.
|
|
|
|
@deprecated use proto_tree_add_boolean() and a subsequent call to PROTO_ITEM_SET_HIDDEN() instead */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_boolean_hidden(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, guint32 value);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a formatted FT_BOOLEAN to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-11 08:18:09 +00:00
|
|
|
proto_tree_add_boolean_format(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
2004-05-10 14:02:17 +00:00
|
|
|
gint length, guint32 value, const char *format, ...) GNUC_FORMAT_CHECK(printf,7,8);
|
2000-03-12 04:48:32 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a FT_FLOAT to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@return the newly created item */
|
2002-08-24 19:45:28 +00:00
|
|
|
extern proto_item *
|
|
|
|
proto_tree_add_float(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, float value);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a hidden FT_FLOAT to a proto_tree.
|
|
|
|
@deprecated use proto_tree_add_float() and a subsequent call to PROTO_ITEM_SET_HIDDEN() instead */
|
2002-08-24 19:45:28 +00:00
|
|
|
extern proto_item *
|
|
|
|
proto_tree_add_float_hidden(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, float value);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a formatted FT_FLOAT to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters
|
|
|
|
@return the newly created item */
|
2002-08-24 19:45:28 +00:00
|
|
|
extern proto_item *
|
|
|
|
proto_tree_add_float_format(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
2004-05-10 14:02:17 +00:00
|
|
|
gint length, float value, const char *format, ...) GNUC_FORMAT_CHECK(printf,7,8);
|
2002-08-24 19:45:28 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a FT_DOUBLE to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_double(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, double value);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a hidden FT_DOUBLE to a proto_tree.
|
|
|
|
@deprecated use proto_tree_add_double() and a subsequent call to PROTO_ITEM_SET_HIDDEN() instead */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_double_hidden(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, double value);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a formatted FT_DOUBLE to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_double_format(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
2004-05-10 14:02:17 +00:00
|
|
|
gint length, double value, const char *format, ...) GNUC_FORMAT_CHECK(printf,7,8);
|
2000-05-31 05:09:07 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add one of FT_UINT8, FT_UINT16, FT_UINT24 or FT_UINT32 to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_uint(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, guint32 value);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a hidden of one of FT_UINT8, FT_UINT16, FT_UINT24 or FT_UINT32 to a proto_tree.
|
|
|
|
@deprecated use proto_tree_add_uint() and a subsequent call to PROTO_ITEM_SET_HIDDEN() instead */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_uint_hidden(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, guint32 value);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a formatted of one of FT_UINT8, FT_UINT16, FT_UINT24 or FT_UINT32 to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-11 08:18:09 +00:00
|
|
|
proto_tree_add_uint_format(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
2004-05-10 14:02:17 +00:00
|
|
|
gint length, guint32 value, const char *format, ...) GNUC_FORMAT_CHECK(printf,7,8);
|
2000-03-12 04:48:32 +00:00
|
|
|
|
2004-08-22 00:31:58 +00:00
|
|
|
/** Add an FT_UINT64 to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@return the newly created item */
|
|
|
|
extern proto_item *
|
|
|
|
proto_tree_add_uint64(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, guint64 value);
|
|
|
|
|
|
|
|
/** Add a formatted FT_UINT64 to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters
|
|
|
|
@return the newly created item */
|
|
|
|
extern proto_item *
|
|
|
|
proto_tree_add_uint64_format(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, guint64 value, const char *format, ...) GNUC_FORMAT_CHECK(printf,7,8);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add one of FT_INT8, FT_INT16, FT_INT24 or FT_INT32 to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_int(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, gint32 value);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a hidden of one of FT_INT8, FT_INT16, FT_INT24 or FT_INT32 to a proto_tree.
|
|
|
|
@deprecated use proto_tree_add_int() and a subsequent call to PROTO_ITEM_SET_HIDDEN() instead */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-31 05:09:07 +00:00
|
|
|
proto_tree_add_int_hidden(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, gint32 value);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Add a formatted of one of FT_INT8, FT_INT16, FT_INT24 or FT_INT32 to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2000-05-11 08:18:09 +00:00
|
|
|
proto_tree_add_int_format(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
2004-05-10 14:02:17 +00:00
|
|
|
gint length, gint32 value, const char *format, ...) GNUC_FORMAT_CHECK(printf,7,8);
|
2000-03-12 04:48:32 +00:00
|
|
|
|
2004-08-22 00:31:58 +00:00
|
|
|
/** Add an FT_INT64 to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@return the newly created item */
|
|
|
|
extern proto_item *
|
|
|
|
proto_tree_add_int64(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, gint64 value);
|
|
|
|
|
|
|
|
/** Add a formatted FT_INT64 to a proto_tree.
|
|
|
|
@param tree the tree to append this item to
|
|
|
|
@param hfindex field index
|
|
|
|
@param tvb the tv buffer of the current data
|
|
|
|
@param start start of data in tvb
|
|
|
|
@param length length of data in tvb
|
|
|
|
@param value data to display
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters
|
|
|
|
@return the newly created item */
|
|
|
|
extern proto_item *
|
|
|
|
proto_tree_add_int64_format(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, gint64 value, const char *format, ...) GNUC_FORMAT_CHECK(printf,7,8);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Useful for quick debugging. Also sends string to STDOUT, so don't
|
|
|
|
* leave call to this function in production code.
|
|
|
|
@param tree the tree to append the text to
|
|
|
|
@param format printf like format string
|
|
|
|
@param ... printf like parameters
|
|
|
|
@return the newly created item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern proto_item *
|
2004-05-10 23:13:55 +00:00
|
|
|
proto_tree_add_debug_text(proto_tree *tree, const char *format,
|
|
|
|
...) GNUC_FORMAT_CHECK(printf,2,3);
|
2000-03-12 04:48:32 +00:00
|
|
|
|
|
|
|
|
1999-07-07 22:52:57 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Append a string to a protocol item.
|
|
|
|
@param pi the item to append the string to
|
|
|
|
@param str the string to append */
|
|
|
|
extern void
|
|
|
|
proto_item_append_string(proto_item *pi, const char *str);
|
|
|
|
|
Convert IPX-and-friend dissectors in packet-ipx.c to use
tvbuffs.
In doing so, I realied that my recommendation for using
tvb_new_subset(pi.compat_top_tvb, -1, -1) was incorrect, because
some dissectors (ethernet!) change pi.len and pi.cap_len. So, I have
to take those two variables into account instead of using -1 and -1.
So, I provide a macro called tvb_create_from_top(offset), where
offset is the name of your offset variable. It is a wrapper around
tvb_new_subset().
I converted the lines that followed my suggestion to use
tvb_create_from_top().
In proto.c I added
proto_tree_add_debug_text(proto_tree*, const char*, ...)
It's much like proto_tree_add_text(), except that it takes no offset
or length; it's soley for temporarily putting debug text into the
proto_tree while debugging a dissector. In making sure that its
use is temporary, the funciton also prints the debug string to stdout
to remind the programmer that the debug code needs to be removed
before shipping the code.
svn path=/trunk/; revision=2068
2000-06-15 03:49:00 +00:00
|
|
|
|
2004-05-01 15:15:08 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Fill given label_str with string representation of field
|
|
|
|
@param fi the item to get the info from
|
|
|
|
@param label_str the string to fill
|
|
|
|
@todo think about changing the parameter profile */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern void
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_item_fill_label(field_info *fi, gchar *label_str);
|
|
|
|
|
2004-05-01 15:15:08 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Register a new protocol.
|
|
|
|
@param name the name of the new protocol
|
|
|
|
@param short_name abbreviated name of the new protocol
|
|
|
|
@param filter_name protocol name used for a display filter string
|
|
|
|
@return the new protocol handle */
|
2004-05-01 15:15:08 +00:00
|
|
|
extern int
|
|
|
|
proto_register_protocol(char *name, char *short_name, char *filter_name);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Register a header_field array.
|
|
|
|
@param parent the protocol handle from proto_register_protocol()
|
|
|
|
@param hf the hf_register_info array
|
|
|
|
@param num_records the number of records in hf */
|
2001-12-18 19:09:08 +00:00
|
|
|
extern void
|
2004-05-01 15:15:08 +00:00
|
|
|
proto_register_field_array(int parent, hf_register_info *hf, int num_records);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Register a protocol subtree (ett) array.
|
|
|
|
@param indices array of ett indices
|
|
|
|
@param num_indices the number of records in indices */
|
2004-05-01 15:15:08 +00:00
|
|
|
extern void
|
|
|
|
proto_register_subtree_array(gint **indices, int num_indices);
|
2001-12-18 19:09:08 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Returns number of items (protocols or header fields) registered.
|
|
|
|
@return the number of items */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern int proto_registrar_n(void);
|
1999-08-26 07:01:44 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Get name of registered header_field number n.
|
|
|
|
@param n item # n (0-indexed)
|
|
|
|
@return the name of this registered item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern char* proto_registrar_get_name(int n);
|
1999-11-11 16:20:25 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Get abbreviation of registered header_field number n.
|
|
|
|
@param n item # n (0-indexed)
|
|
|
|
@return the abbreviation of this registered item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern char* proto_registrar_get_abbrev(int n);
|
1999-08-26 07:01:44 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Get the header_field information based upon a field or protocol id.
|
|
|
|
@param hfindex item # n (0-indexed)
|
|
|
|
@return the registered item */
|
2003-11-21 14:58:49 +00:00
|
|
|
extern header_field_info* proto_registrar_get_nth(guint hfindex);
|
2000-04-03 09:24:12 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Get the header_field information based upon a field name.
|
|
|
|
@param field_name the field name to search for
|
|
|
|
@return the registered item */
|
2002-04-29 07:55:32 +00:00
|
|
|
extern header_field_info* proto_registrar_get_byname(char *field_name);
|
2002-04-18 20:19:10 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Get enum ftenum FT_ of registered header_field number n.
|
|
|
|
@param n item # n (0-indexed)
|
|
|
|
@return the registered item */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern int proto_registrar_get_ftype(int n);
|
1999-08-26 07:01:44 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Get parent protocol of registered header_field number n.
|
|
|
|
@param n item # n (0-indexed)
|
|
|
|
@return -1 if item _is_ a protocol */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern int proto_registrar_get_parent(int n);
|
1999-08-26 07:01:44 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Is item #n a protocol?
|
|
|
|
@param n item # n (0-indexed)
|
|
|
|
@return TRUE if it's a protocol, FALSE if it's not */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern gboolean proto_registrar_is_protocol(int n);
|
1999-08-26 07:01:44 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/* Get length of registered field according to field type.
|
|
|
|
@param n item # n (0-indexed)
|
|
|
|
@return 0 means undeterminable at registration time, * -1 means unknown field */
|
|
|
|
extern gint proto_registrar_get_length(int n);
|
2001-01-03 06:56:03 +00:00
|
|
|
|
|
|
|
|
2003-08-25 00:15:02 +00:00
|
|
|
/* Routines to use to iterate over the protocols and their fields;
|
|
|
|
* they return the item number of the protocol in question or the
|
|
|
|
* appropriate hfinfo pointer, and keep state in "*cookie". */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern int proto_get_first_protocol(void **cookie);
|
|
|
|
extern int proto_get_next_protocol(void **cookie);
|
2003-08-25 00:15:02 +00:00
|
|
|
extern header_field_info *proto_get_first_protocol_field(int proto_id, void **cookle);
|
|
|
|
extern header_field_info *proto_get_next_protocol_field(void **cookle);
|
2001-01-03 06:56:03 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Given a protocol's filter_name.
|
|
|
|
@param filter_name the filter name to search for
|
|
|
|
@return proto_id */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern int proto_get_id_by_filter_name(gchar* filter_name);
|
2001-04-01 22:50:08 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Can item #n decoding be disabled?
|
|
|
|
@param proto_id protocol id (0-indexed)
|
|
|
|
@return TRUE if it's a protocol, FALSE if it's not */
|
|
|
|
extern gboolean proto_can_toggle_protocol(int proto_id);
|
|
|
|
|
|
|
|
/** Get the "protocol_t" structure for the given protocol's item number.
|
|
|
|
@param proto_id protocol id (0-indexed) */
|
2003-11-16 23:17:27 +00:00
|
|
|
extern protocol_t *find_protocol_by_id(int proto_id);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Get the protocol's name for the given protocol's item number.
|
|
|
|
@param proto_id protocol id (0-indexed)
|
|
|
|
@return its name */
|
|
|
|
extern char *proto_get_protocol_name(int proto_id);
|
2001-01-03 06:56:03 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Get the protocol's item number, for the given protocol's "protocol_t".
|
|
|
|
@return its proto_id */
|
|
|
|
extern int proto_get_id(protocol_t *protocol);
|
|
|
|
|
|
|
|
/** Get the protocol's short name, for the given protocol's "protocol_t".
|
|
|
|
@return its short name. */
|
2003-11-16 23:17:27 +00:00
|
|
|
extern char *proto_get_protocol_short_name(protocol_t *protocol);
|
2001-01-03 06:56:03 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Is protocol's decoding enabled ?
|
|
|
|
@param protocol
|
|
|
|
@return TRUE if decoding is enabled, FALSE if not */
|
|
|
|
extern gboolean proto_is_protocol_enabled(protocol_t *protocol);
|
|
|
|
|
|
|
|
/** Get a protocol's filter name by it's item number.
|
|
|
|
@param proto_id protocol id (0-indexed)
|
|
|
|
@return its filter name. */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern char *proto_get_protocol_filter_name(int proto_id);
|
Add the "Edit:Protocols..." feature which currently only implements
the following:
It is now possible to enable/disable a particular protocol decoding
(i.e. the protocol dissector is void or not). When a protocol
is disabled, it is displayed as Data and of course, all linked
sub-protocols are disabled as well.
Disabling a protocol could be interesting:
- in case of buggy dissectors
- in case of wrong heuristics
- for performance reasons
- to decode the data as another protocol (TODO)
Currently (if I am not wrong), all dissectors but NFS can be disabled
(and dissectors that do not register protocols :-)
I do not like the way the RPC sub-dissectors are disabled (in the
sub-dissectors) since this could be done in the RPC dissector itself,
knowing the sub-protocol hfinfo entry (this is why, I've not modified
the NFS one yet).
Two functions are added in proto.c :
gboolean proto_is_protocol_enabled(int n);
void proto_set_decoding(int n, gboolean enabled);
and two MACROs which can be used in dissectors:
OLD_CHECK_DISPLAY_AS_DATA(index, pd, offset, fd, tree)
CHECK_DISPLAY_AS_DATA(index, tvb, pinfo, tree)
See also the XXX in proto_dlg.c and proto.c around the new functions.
svn path=/trunk/; revision=2267
2000-08-13 14:09:15 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Enable / Disable protocol of the given item number.
|
|
|
|
@param proto_id protocol id (0-indexed)
|
|
|
|
@param enabled enable / disable the protocol */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern void proto_set_decoding(int proto_id, gboolean enabled);
|
2001-01-03 06:56:03 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Disable disabling/enabling of protocol of the given item number.
|
|
|
|
@param proto_id protocol id (0-indexed) */
|
2004-01-03 18:40:08 +00:00
|
|
|
extern void proto_set_cant_toggle(int proto_id);
|
Add the "Edit:Protocols..." feature which currently only implements
the following:
It is now possible to enable/disable a particular protocol decoding
(i.e. the protocol dissector is void or not). When a protocol
is disabled, it is displayed as Data and of course, all linked
sub-protocols are disabled as well.
Disabling a protocol could be interesting:
- in case of buggy dissectors
- in case of wrong heuristics
- for performance reasons
- to decode the data as another protocol (TODO)
Currently (if I am not wrong), all dissectors but NFS can be disabled
(and dissectors that do not register protocols :-)
I do not like the way the RPC sub-dissectors are disabled (in the
sub-dissectors) since this could be done in the RPC dissector itself,
knowing the sub-protocol hfinfo entry (this is why, I've not modified
the NFS one yet).
Two functions are added in proto.c :
gboolean proto_is_protocol_enabled(int n);
void proto_set_decoding(int n, gboolean enabled);
and two MACROs which can be used in dissectors:
OLD_CHECK_DISPLAY_AS_DATA(index, pd, offset, fd, tree)
CHECK_DISPLAY_AS_DATA(index, tvb, pinfo, tree)
See also the XXX in proto_dlg.c and proto.c around the new functions.
svn path=/trunk/; revision=2267
2000-08-13 14:09:15 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Checks for existence any protocol or field within a tree.
|
|
|
|
@param tree "Protocols" are assumed to be a child of the [empty] root node.
|
|
|
|
@param id ???
|
|
|
|
@return TRUE = found, FALSE = not found
|
|
|
|
@todo add explanation of id parameter */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern gboolean proto_check_for_protocol_or_field(proto_tree* tree, int id);
|
1999-08-29 04:06:43 +00:00
|
|
|
|
2000-07-22 15:58:54 +00:00
|
|
|
/* Return GPtrArray* of field_info pointers for all hfindex that appear in
|
2003-12-06 06:09:13 +00:00
|
|
|
* tree. Only works with primed trees, and is fast. */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern GPtrArray* proto_get_finfo_ptr_array(proto_tree *tree, int hfindex);
|
1999-07-07 22:52:57 +00:00
|
|
|
|
2003-12-06 06:09:13 +00:00
|
|
|
/* Return GPtrArray* of field_info pointers for all hfindex that appear in
|
|
|
|
* tree. Works with any tree, primed or unprimed, and is slower than
|
|
|
|
* proto_get_finfo_ptr_array because it has to search through the tree. */
|
|
|
|
extern GPtrArray* proto_find_finfo(proto_tree *tree, int hfindex);
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Dumps a glossary of the protocol registrations to STDOUT */
|
2002-05-14 10:15:12 +00:00
|
|
|
extern void proto_registrar_dump_protocols(void);
|
|
|
|
|
2004-09-10 15:21:20 +00:00
|
|
|
/** Dumps a glossary of the field value strings or true/false strings to STDOUT */
|
|
|
|
extern void proto_registrar_dump_values(void);
|
|
|
|
|
|
|
|
/** Dumps a glossary of the protocol and field registrations to STDOUT.
|
|
|
|
* Format 1 is the original format. Format 2 includes the base (for integers)
|
|
|
|
* and the blurb. */
|
|
|
|
extern void proto_registrar_dump_fields(int format);
|
1999-07-15 15:33:52 +00:00
|
|
|
|
2004-05-01 15:15:08 +00:00
|
|
|
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Points to the first element of an array of Booleans, indexed by
|
|
|
|
a subtree item type. That array element is TRUE if subtrees of
|
2004-05-09 10:03:41 +00:00
|
|
|
an item of that type are to be expanded. With MSVC and a
|
2004-05-10 23:13:55 +00:00
|
|
|
libethereal.dll, we need a special declaration. */
|
2004-05-09 10:03:41 +00:00
|
|
|
ETH_VAR_IMPORT gboolean *tree_is_expanded;
|
1999-11-16 11:44:20 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Number of elements in the tree_is_expanded array. With MSVC and a
|
|
|
|
* libethereal.dll, we need a special declaration. */
|
2004-05-09 10:03:41 +00:00
|
|
|
ETH_VAR_IMPORT int num_tree_types;
|
1999-11-16 11:44:20 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** glib doesn't have g_ptr_array_len of all things!*/
|
2000-07-22 15:58:54 +00:00
|
|
|
#ifndef g_ptr_array_len
|
|
|
|
#define g_ptr_array_len(a) ((a)->len)
|
|
|
|
#endif
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Get number of bits of a header_field.
|
|
|
|
@param hfinfo header_field
|
|
|
|
@return the bitwidth */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern int
|
2001-02-01 20:21:25 +00:00
|
|
|
hfinfo_bitwidth(header_field_info *hfinfo);
|
|
|
|
|
2004-05-01 15:15:08 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
Rename "proto_alloc_dfilter_string()" to
"proto_construct_dfilter_string()", to more accurately reflect what it
does.
Give it, and "proto_can_match_selected()", an "epan_dissect_t *"
argument, which replaces the raw data pointer argument to
"proto_construct_dfilter_string()".
For fields that don't have a type we can directly filter on, we don't
support filtering on the field as raw data if:
the "epan_dissect_t *" argument is null;
the data source tvbuff for the field isn't the tvbuff for the
"epan_dissect_t" in question (i.e., it's in the result of a
reassembly, and "frame[N:M]" can't get at it).
Trim the length the raw data in the case of such a field to the length
of the tvbuff for the "epan_dissect_t" in question, so we don't go past
it. Fetch the raw data bytes to match from that tvbuff.
Have "proto_construct_dfilter_string()" return a null pointer if it
can't construct the filter string, and have "protocolinfo_packet()" in
the tap-protocolinfo tap ignore a field if
"proto_construct_dfilter_string()" can't construct a filter string for
it - and have it pass NULL as the "epan_dissect_t *", for now. If
somebody decides it makes sense to dump out a "frame[N:M] =" value for
non-registered fields, it can be changed to pass "edt".
svn path=/trunk/; revision=7635
2003-05-03 00:48:37 +00:00
|
|
|
#include "epan.h"
|
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Can we do a "match selected" on this field.
|
|
|
|
@param finfo field_info
|
|
|
|
@param edt epan dissecting
|
|
|
|
@return TRUE if we can do a "match selected" on the field, FALSE otherwise. */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern gboolean
|
Rename "proto_alloc_dfilter_string()" to
"proto_construct_dfilter_string()", to more accurately reflect what it
does.
Give it, and "proto_can_match_selected()", an "epan_dissect_t *"
argument, which replaces the raw data pointer argument to
"proto_construct_dfilter_string()".
For fields that don't have a type we can directly filter on, we don't
support filtering on the field as raw data if:
the "epan_dissect_t *" argument is null;
the data source tvbuff for the field isn't the tvbuff for the
"epan_dissect_t" in question (i.e., it's in the result of a
reassembly, and "frame[N:M]" can't get at it).
Trim the length the raw data in the case of such a field to the length
of the tvbuff for the "epan_dissect_t" in question, so we don't go past
it. Fetch the raw data bytes to match from that tvbuff.
Have "proto_construct_dfilter_string()" return a null pointer if it
can't construct the filter string, and have "protocolinfo_packet()" in
the tap-protocolinfo tap ignore a field if
"proto_construct_dfilter_string()" can't construct a filter string for
it - and have it pass NULL as the "epan_dissect_t *", for now. If
somebody decides it makes sense to dump out a "frame[N:M] =" value for
non-registered fields, it can be changed to pass "edt".
svn path=/trunk/; revision=7635
2003-05-03 00:48:37 +00:00
|
|
|
proto_can_match_selected(field_info *finfo, epan_dissect_t *edt);
|
Enable "Match Selected" only if there's a field selected *and* we can do
a "Match Selected" on it - we can't do a "Match Selected" if the field
has no value (e.g., FT_NULL) and has a length of 0.
If we unselect the current packet, we don't have a protocol tree, so we
don't have a currently selected field - clear the "Match Selected" menu
item and the display in the status line of information about the
currently selected field.
Move the low-level statusbar manipulation into "gtk/main.c", in routines
whose API doesn't expose anything GTK+-ish.
"close_cap_file()" calls one of those routines to clear out the status
bar, so it doesn't need to take a pointer to the statusbar widget as an
argument.
"clear_tree_and_hex_views()" is purely a display-manipulating routine;
move it to "gtk/proto_draw.c".
Extract from "tree_view_unselect_row_cb()" an "unselect_field()" routine
to do all the work that needs to be done if the currently selected
protocol tree row is unselected, and call it if the currently selected
packet list row is unselected (if it's unselected, there *is* no
protocol tree, so no row can be selected), as well as from
"tree_view_unselect_row_cb()".
Before pushing a new field-description message onto the statusbar, pop
the old one off.
Get rid of an unused variable (set, but not used).
svn path=/trunk/; revision=3513
2001-06-05 07:39:31 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Construct a display filter string.
|
|
|
|
@param finfo field_info
|
|
|
|
@param edt epan dissecting
|
|
|
|
@return the display filter string */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern char*
|
Rename "proto_alloc_dfilter_string()" to
"proto_construct_dfilter_string()", to more accurately reflect what it
does.
Give it, and "proto_can_match_selected()", an "epan_dissect_t *"
argument, which replaces the raw data pointer argument to
"proto_construct_dfilter_string()".
For fields that don't have a type we can directly filter on, we don't
support filtering on the field as raw data if:
the "epan_dissect_t *" argument is null;
the data source tvbuff for the field isn't the tvbuff for the
"epan_dissect_t" in question (i.e., it's in the result of a
reassembly, and "frame[N:M]" can't get at it).
Trim the length the raw data in the case of such a field to the length
of the tvbuff for the "epan_dissect_t" in question, so we don't go past
it. Fetch the raw data bytes to match from that tvbuff.
Have "proto_construct_dfilter_string()" return a null pointer if it
can't construct the filter string, and have "protocolinfo_packet()" in
the tap-protocolinfo tap ignore a field if
"proto_construct_dfilter_string()" can't construct a filter string for
it - and have it pass NULL as the "epan_dissect_t *", for now. If
somebody decides it makes sense to dump out a "frame[N:M] =" value for
non-registered fields, it can be changed to pass "edt".
svn path=/trunk/; revision=7635
2003-05-03 00:48:37 +00:00
|
|
|
proto_construct_dfilter_string(field_info *finfo, epan_dissect_t *edt);
|
2000-08-30 02:50:18 +00:00
|
|
|
|
2004-05-10 23:13:55 +00:00
|
|
|
/** Find field from offset in tvb.
|
|
|
|
@param tree
|
|
|
|
@param offset offset in the tvb
|
|
|
|
@param tvb the tv buffer
|
|
|
|
@return the corresponding field_info */
|
Put "extern" in front of a pile of function declarations.
It makes no difference if they really are function declarations;
however, in plugins, when building on OSes that don't let
dynamically-loaded modules access functions in the main program (e.g.,
Windows), when compiling a plugin, <plugin_api.h> defines the names of
those functions as (*pointer_name), so they turn into declarations of
pointer variables pointing to the functions in question, and, on
platforms with a def/ref model in the linker, if a plugin has more than
one source file that gets linked into the plugin, the linker may get
upset at two definitions of the same variable.
svn path=/trunk/; revision=4114
2001-10-31 07:47:27 +00:00
|
|
|
extern field_info*
|
2002-02-18 01:08:44 +00:00
|
|
|
proto_find_field_from_offset(proto_tree *tree, guint offset, tvbuff_t *tvb);
|
2001-03-02 23:10:12 +00:00
|
|
|
|
1999-07-07 22:52:57 +00:00
|
|
|
#endif /* proto.h */
|