1999-07-07 22:52:57 +00:00
|
|
|
/* proto.h
|
|
|
|
* Definitions for protocol display
|
|
|
|
*
|
2003-12-04 10:59:34 +00:00
|
|
|
* $Id: proto.h,v 1.52 2003/12/04 10:59:34 guy Exp $
|
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.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#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
|
|
|
|
2002-02-05 22:10:20 +00:00
|
|
|
struct _value_string;
|
1999-07-07 22:52:57 +00:00
|
|
|
|
|
|
|
#define ITEM_LABEL_LENGTH 240
|
|
|
|
|
|
|
|
/* In order to make a const value_string[] look like a value_string*, I
|
|
|
|
* need this macro */
|
2002-11-28 01:46:14 +00:00
|
|
|
#define VALS(x) (const struct _value_string*)(x)
|
1999-07-07 22:52:57 +00:00
|
|
|
|
1999-10-12 06:21:15 +00:00
|
|
|
/* ... and similarly, */
|
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
|
|
|
|
2003-11-16 23:17:27 +00:00
|
|
|
struct _protocol;
|
|
|
|
|
|
|
|
typedef struct _protocol protocol_t;
|
|
|
|
|
2001-11-26 05:13:14 +00:00
|
|
|
/* check protocol activation */
|
|
|
|
#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
|
|
|
enum {
|
|
|
|
BASE_NONE,
|
|
|
|
BASE_DEC,
|
|
|
|
BASE_HEX,
|
2003-01-31 03:17:56 +00:00
|
|
|
BASE_OCT
|
1999-10-12 06:21:15 +00:00
|
|
|
};
|
|
|
|
|
2001-02-01 20:21:25 +00:00
|
|
|
typedef struct _header_field_info header_field_info;
|
|
|
|
|
1999-07-15 15:33:52 +00:00
|
|
|
/* information describing a header field */
|
2001-02-01 20:21:25 +00:00
|
|
|
struct _header_field_info {
|
|
|
|
/* ---------- set by dissector --------- */
|
1999-07-07 22:52:57 +00:00
|
|
|
char *name;
|
|
|
|
char *abbrev;
|
|
|
|
enum ftenum type;
|
2000-03-12 04:48:32 +00:00
|
|
|
int display; /* for integers only, so far. Base */
|
2002-11-28 01:46:14 +00:00
|
|
|
const void *strings; /* val_string or true_false_string */
|
1999-10-12 06:21:15 +00:00
|
|
|
guint32 bitmask;
|
|
|
|
char *blurb; /* Brief description of field. */
|
|
|
|
|
2001-02-01 20:21:25 +00:00
|
|
|
/* ---------- set by proto routines --------- */
|
|
|
|
int id; /* Field ID */
|
1999-10-12 06:21:15 +00:00
|
|
|
int parent; /* parent protocol */
|
|
|
|
int bitshift; /* bits to shift */
|
2001-02-13 18:34:51 +00:00
|
|
|
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
|
|
|
|
2001-06-18 02:18:27 +00:00
|
|
|
/*
|
|
|
|
* HFILL initializes all the "set by proto routines" fields in a
|
|
|
|
* "header_field_info"; if new fields are added or removed, it should
|
|
|
|
* be changed as necessary.
|
|
|
|
*/
|
|
|
|
#define HFILL 0, 0, 0, NULL, NULL
|
2000-04-03 09:24:12 +00:00
|
|
|
|
1999-07-07 22:52:57 +00:00
|
|
|
/* Used when registering many fields at once */
|
|
|
|
typedef struct hf_register_info {
|
|
|
|
int *p_id; /* pointer to int; written to by register() function */
|
1999-07-15 15:33:52 +00:00
|
|
|
header_field_info hfinfo;
|
1999-07-07 22:52:57 +00:00
|
|
|
} hf_register_info;
|
|
|
|
|
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;
|
|
|
|
|
2001-12-18 19:09:08 +00:00
|
|
|
/* Contains the field information for the proto_item. */
|
1999-07-07 22:52:57 +00:00
|
|
|
typedef struct field_info {
|
2003-12-03 09:28:26 +00:00
|
|
|
header_field_info *hfinfo;
|
1999-07-07 22:52:57 +00:00
|
|
|
gint start;
|
|
|
|
gint length;
|
|
|
|
gint tree_type; /* ETT_* */
|
2003-11-25 14:07:45 +00:00
|
|
|
item_label_t *rep; /* string for GUI tree */
|
1999-07-07 22:52:57 +00:00
|
|
|
int visible;
|
2002-02-18 01:08:44 +00:00
|
|
|
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;
|
|
|
|
|
2001-12-18 19:09:08 +00:00
|
|
|
/* One of these exists for the entire protocol tree. Each proto_node
|
|
|
|
* in the protocol tree points to the same copy. */
|
|
|
|
typedef struct {
|
|
|
|
GHashTable *interesting_hfids;
|
|
|
|
gboolean visible;
|
|
|
|
} tree_data_t;
|
|
|
|
|
2003-12-04 10:59:34 +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-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;
|
|
|
|
|
2003-12-04 10:59:34 +00:00
|
|
|
typedef proto_node proto_tree;
|
|
|
|
typedef proto_node proto_item;
|
2001-12-18 19:09: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
|
|
|
|
|
|
|
/* Retrieve the field_info from a proto_item */
|
2003-12-04 10:59:34 +00:00
|
|
|
#define PITEM_FINFO(t) ((t)->finfo)
|
2001-12-18 19:09:08 +00:00
|
|
|
|
|
|
|
/* Retrieve the tree_data_t from a proto_tree */
|
2003-12-04 10:59:34 +00:00
|
|
|
#define PTREE_DATA(t) ((t)->tree_data)
|
1999-07-07 22:52:57 +00:00
|
|
|
|
1999-08-26 06:20:50 +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
|
|
|
|
|
|
|
/* 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
|
|
|
|
2000-01-22 04:59:55 +00:00
|
|
|
/* Set text of proto_item after having already been created. */
|
2001-07-22 10:25:50 +00:00
|
|
|
#if __GNUC__ >= 2
|
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, ...)
|
2000-03-07 05:54:52 +00:00
|
|
|
__attribute__((format (printf, 2, 3)));
|
|
|
|
#else
|
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, ...);
|
2000-03-07 05:54:52 +00:00
|
|
|
#endif
|
2000-01-22 04:59:55 +00:00
|
|
|
|
2001-08-29 00:51:10 +00:00
|
|
|
/* Append to text of proto_item after having already been created. */
|
|
|
|
#if __GNUC__ >= 2
|
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, ...)
|
2001-08-29 00:51:10 +00:00
|
|
|
__attribute__((format (printf, 2, 3)));
|
|
|
|
#else
|
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, ...);
|
2001-08-29 00:51:10 +00:00
|
|
|
#endif
|
|
|
|
|
1999-10-12 06:21:15 +00:00
|
|
|
/* Set length of proto_item after having already been created. */
|
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
|
|
|
|
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,
|
|
|
|
* we need to pass in a tvbuff - the end offset is relative to the beginning
|
|
|
|
* of that tvbuff.
|
|
|
|
*/
|
|
|
|
extern void proto_item_set_end(proto_item *pi, tvbuff_t *tvb, gint end);
|
|
|
|
|
2000-07-27 06:41:59 +00:00
|
|
|
/* Get length of proto_item. Useful after using proto_tree_add_item()
|
|
|
|
* to add a variable-length field (e.g., FT_NSTRING_UINT8) */
|
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
|
|
|
|
1999-10-12 06:21:15 +00:00
|
|
|
/* Creates new proto_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
|
|
|
|
2002-08-28 20:41:00 +00:00
|
|
|
/* Mark a field/protocol ID as "interesting". */
|
2002-04-18 20:19:10 +00:00
|
|
|
extern void
|
2001-12-18 19:09:08 +00:00
|
|
|
proto_tree_prime_hfid(proto_tree *tree, int hfid);
|
|
|
|
|
1999-10-12 06:21:15 +00:00
|
|
|
/* Clear memory for entry proto_tree. Clears proto_tree struct also. */
|
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
|
|
|
|
|
|
|
/* Create a subtree under an existing item; returns tree pointer */
|
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_item_add_subtree(proto_item *ti, gint idx);
|
1999-07-07 22:52:57 +00:00
|
|
|
|
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
|
1999-07-07 22:52:57 +00:00
|
|
|
proto_register_field(char *name, char *abbrev, enum ftenum type, int parent,
|
2002-02-05 22:10:20 +00:00
|
|
|
struct _value_string* vals);
|
1999-07-07 22:52:57 +00:00
|
|
|
|
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-01-03 06:56:03 +00:00
|
|
|
proto_register_protocol(char *name, char *short_name, char *filter_name);
|
1999-07-07 22:52:57 +00:00
|
|
|
|
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-15 15:33:52 +00:00
|
|
|
proto_register_field_array(int parent, hf_register_info *hf, int num_records);
|
1999-07-07 22:52:57 +00:00
|
|
|
|
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-11-16 11:44:20 +00:00
|
|
|
proto_register_subtree_array(gint **indices, int num_indices);
|
|
|
|
|
2000-05-31 05:09:07 +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. */
|
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);
|
|
|
|
|
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);
|
|
|
|
|
|
|
|
/* Add a FT_NONE to a proto_tree */
|
2001-07-22 10:25:50 +00:00
|
|
|
#if __GNUC__ >= 2
|
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,
|
|
|
|
gint length, const char *format, ...)
|
|
|
|
__attribute__((format (printf, 6, 7)));
|
|
|
|
#else
|
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,
|
|
|
|
gint length, const char *format, ...);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* Add a FT_PROTOCOL to a proto_tree */
|
2001-07-22 10:25:50 +00:00
|
|
|
#if __GNUC__ >= 2
|
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,
|
2000-03-12 04:48:32 +00:00
|
|
|
gint length, const char *format, ...)
|
2000-05-11 08:18:09 +00:00
|
|
|
__attribute__((format (printf, 6, 7)));
|
2000-03-12 04:48:32 +00:00
|
|
|
#else
|
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,
|
2000-03-12 04:48:32 +00:00
|
|
|
gint length, const char *format, ...);
|
|
|
|
#endif
|
1999-07-07 22:52:57 +00:00
|
|
|
|
2000-05-31 05:09:07 +00:00
|
|
|
/* Add a FT_BYTES to a proto_tree */
|
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);
|
|
|
|
|
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
|
|
|
|
2001-07-22 10:25:50 +00:00
|
|
|
#if __GNUC__ >= 2
|
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,
|
2000-03-14 06:03:26 +00:00
|
|
|
gint length, const guint8* start_ptr, const char *format, ...)
|
2000-05-11 08:18:09 +00:00
|
|
|
__attribute__((format (printf, 7, 8)));
|
2000-03-12 04:48:32 +00:00
|
|
|
#else
|
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,
|
2000-03-14 06:03:26 +00:00
|
|
|
gint length, const guint8* start_ptr, const char *format, ...);
|
2000-03-12 04:48:32 +00:00
|
|
|
#endif
|
2000-01-22 04:59:55 +00:00
|
|
|
|
2000-05-31 05:09:07 +00:00
|
|
|
/* Add a FT_*TIME to a proto_tree */
|
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
|
|
|
|
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
|
|
|
|
2001-07-22 10:25:50 +00:00
|
|
|
#if __GNUC__ >= 2
|
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,
|
2001-09-14 07:10:13 +00:00
|
|
|
gint length, nstime_t* value_ptr, const char *format, ...)
|
2000-05-11 08:18:09 +00:00
|
|
|
__attribute__((format (printf, 7, 8)));
|
2000-03-12 04:48:32 +00:00
|
|
|
#else
|
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,
|
2001-09-14 07:10:13 +00:00
|
|
|
gint length, nstime_t* value_ptr, const char *format, ...);
|
2000-03-12 04:48:32 +00:00
|
|
|
#endif
|
|
|
|
|
2000-05-31 05:09:07 +00:00
|
|
|
/* Add a FT_IPXNET to a proto_tree */
|
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);
|
|
|
|
|
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);
|
|
|
|
|
2001-07-22 10:25:50 +00:00
|
|
|
#if __GNUC__ >= 2
|
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,
|
2000-03-12 04:48:32 +00:00
|
|
|
gint length, guint32 value, const char *format, ...)
|
2000-05-11 08:18:09 +00:00
|
|
|
__attribute__((format (printf, 7, 8)));
|
2000-03-12 04:48:32 +00:00
|
|
|
#else
|
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,
|
2000-03-12 04:48:32 +00:00
|
|
|
gint length, guint32 value, const char *format, ...);
|
|
|
|
#endif
|
|
|
|
|
2000-05-31 05:09:07 +00:00
|
|
|
/* Add a FT_IPv4 to a proto_tree */
|
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);
|
|
|
|
|
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);
|
|
|
|
|
2001-07-22 10:25:50 +00:00
|
|
|
#if __GNUC__ >= 2
|
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,
|
2000-03-12 04:48:32 +00:00
|
|
|
gint length, guint32 value, const char *format, ...)
|
2000-05-11 08:18:09 +00:00
|
|
|
__attribute__((format (printf, 7, 8)));
|
2000-03-12 04:48:32 +00:00
|
|
|
#else
|
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,
|
2000-03-12 04:48:32 +00:00
|
|
|
gint length, guint32 value, const char *format, ...);
|
|
|
|
#endif
|
|
|
|
|
2000-05-31 05:09:07 +00:00
|
|
|
/* Add a FT_IPv6 to a proto_tree */
|
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);
|
|
|
|
|
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);
|
|
|
|
|
2001-07-22 10:25:50 +00:00
|
|
|
#if __GNUC__ >= 2
|
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,
|
2000-05-31 05:09:07 +00:00
|
|
|
gint length, const guint8* value_ptr, const char *format, ...)
|
2000-05-11 08:18:09 +00:00
|
|
|
__attribute__((format (printf, 7, 8)));
|
2000-03-12 04:48:32 +00:00
|
|
|
#else
|
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,
|
2000-05-31 05:09:07 +00:00
|
|
|
gint length, const guint8* value_ptr, const char *format, ...);
|
2000-03-12 04:48:32 +00:00
|
|
|
#endif
|
|
|
|
|
2000-05-31 05:09:07 +00:00
|
|
|
/* Add a FT_ETHER to a proto_tree */
|
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);
|
|
|
|
|
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);
|
|
|
|
|
2001-07-22 10:25:50 +00:00
|
|
|
#if __GNUC__ >= 2
|
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,
|
2000-05-31 05:09:07 +00:00
|
|
|
gint length, const guint8* value, const char *format, ...)
|
2000-05-11 08:18:09 +00:00
|
|
|
__attribute__((format (printf, 7, 8)));
|
2000-03-12 04:48:32 +00:00
|
|
|
#else
|
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,
|
2000-05-31 18:32:15 +00:00
|
|
|
gint length, const guint8* value, const char *format, ...);
|
2000-03-12 04:48:32 +00:00
|
|
|
#endif
|
|
|
|
|
2000-05-31 05:09:07 +00:00
|
|
|
/* Add a FT_STRING to a proto_tree */
|
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);
|
|
|
|
|
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);
|
|
|
|
|
2001-07-22 10:25:50 +00:00
|
|
|
#if __GNUC__ >= 2
|
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,
|
2000-03-14 06:03:26 +00:00
|
|
|
gint length, const char* value, const char *format, ...)
|
2000-05-11 08:18:09 +00:00
|
|
|
__attribute__((format (printf, 7, 8)));
|
2000-03-12 04:48:32 +00:00
|
|
|
#else
|
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,
|
2000-03-14 06:03:26 +00:00
|
|
|
gint length, const char* value, const char *format, ...);
|
2000-03-12 04:48:32 +00:00
|
|
|
#endif
|
|
|
|
|
2003-10-29 23:48:14 +00:00
|
|
|
extern void
|
|
|
|
proto_item_append_string(proto_item *pi, const char *str);
|
|
|
|
|
2000-05-31 05:09:07 +00:00
|
|
|
/* Add a FT_BOOLEAN to a proto_tree */
|
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);
|
|
|
|
|
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);
|
|
|
|
|
2001-07-22 10:25:50 +00:00
|
|
|
#if __GNUC__ >= 2
|
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,
|
2000-03-12 04:48:32 +00:00
|
|
|
gint length, guint32 value, const char *format, ...)
|
2000-05-11 08:18:09 +00:00
|
|
|
__attribute__((format (printf, 7, 8)));
|
2000-03-12 04:48:32 +00:00
|
|
|
#else
|
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,
|
2000-03-12 04:48:32 +00:00
|
|
|
gint length, guint32 value, const char *format, ...);
|
|
|
|
#endif
|
|
|
|
|
2002-08-24 19:45:28 +00:00
|
|
|
/* Add a FT_FLOAT to a proto_tree */
|
|
|
|
extern proto_item *
|
|
|
|
proto_tree_add_float(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, float value);
|
|
|
|
|
|
|
|
extern proto_item *
|
|
|
|
proto_tree_add_float_hidden(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, float value);
|
|
|
|
|
|
|
|
#if __GNUC__ >= 2
|
|
|
|
extern proto_item *
|
|
|
|
proto_tree_add_float_format(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, float value, const char *format, ...)
|
|
|
|
__attribute__((format (printf, 7, 8)));
|
|
|
|
#else
|
|
|
|
extern proto_item *
|
|
|
|
proto_tree_add_float_format(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, float value, const char *format, ...);
|
|
|
|
#endif
|
|
|
|
|
2000-05-31 05:09:07 +00:00
|
|
|
/* Add a FT_DOUBLE to a proto_tree */
|
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);
|
|
|
|
|
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);
|
|
|
|
|
2001-07-22 10:25:50 +00:00
|
|
|
#if __GNUC__ >= 2
|
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,
|
|
|
|
gint length, double value, const char *format, ...)
|
|
|
|
__attribute__((format (printf, 7, 8)));
|
|
|
|
#else
|
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,
|
|
|
|
gint length, double value, const char *format, ...);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* Add any FT_UINT* to a proto_tree */
|
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);
|
|
|
|
|
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);
|
|
|
|
|
2001-07-22 10:25:50 +00:00
|
|
|
#if __GNUC__ >= 2
|
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,
|
2000-03-12 04:48:32 +00:00
|
|
|
gint length, guint32 value, const char *format, ...)
|
2000-05-11 08:18:09 +00:00
|
|
|
__attribute__((format (printf, 7, 8)));
|
2000-03-12 04:48:32 +00:00
|
|
|
#else
|
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,
|
2000-03-12 04:48:32 +00:00
|
|
|
gint length, guint32 value, const char *format, ...);
|
|
|
|
#endif
|
|
|
|
|
2000-05-31 05:09:07 +00:00
|
|
|
/* Add any FT_INT* to a proto_tree */
|
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);
|
|
|
|
|
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);
|
|
|
|
|
2001-07-22 10:25:50 +00:00
|
|
|
#if __GNUC__ >= 2
|
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,
|
2000-04-25 21:43:50 +00:00
|
|
|
gint length, gint32 value, const char *format, ...)
|
2000-05-11 08:18:09 +00:00
|
|
|
__attribute__((format (printf, 7, 8)));
|
2000-04-25 21:43:50 +00:00
|
|
|
#else
|
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,
|
2000-04-25 21:43:50 +00:00
|
|
|
gint length, gint32 value, const char *format, ...);
|
|
|
|
#endif
|
|
|
|
|
2000-03-12 04:48:32 +00:00
|
|
|
|
2000-05-31 05:09:07 +00:00
|
|
|
/* Add a text-only node to the proto_tree */
|
2001-07-22 10:25:50 +00:00
|
|
|
#if __GNUC__ >= 2
|
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_text(proto_tree *tree, tvbuff_t *tvb, gint start, gint length, const char *,
|
|
|
|
...) __attribute__((format (printf, 5, 6)));
|
2000-03-12 04:48:32 +00:00
|
|
|
#else
|
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_text(proto_tree *tree, tvbuff_t *tvb, gint start, gint length, const char *,
|
2000-03-12 04:48:32 +00:00
|
|
|
...);
|
|
|
|
#endif
|
|
|
|
|
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-08-10 16:04:33 +00:00
|
|
|
proto_tree_add_text_valist(proto_tree *tree, tvbuff_t *tvb, gint start,
|
|
|
|
gint length, const char *format, va_list ap);
|
2000-03-12 04:48:32 +00:00
|
|
|
|
1999-07-07 22:52:57 +00:00
|
|
|
|
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
|
|
|
/* Useful for quick debugging. Also sends string to STDOUT, so don't
|
|
|
|
* leave call to this function in production code. */
|
2001-07-22 10:25:50 +00:00
|
|
|
#if __GNUC__ >= 2
|
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 *
|
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
|
|
|
proto_tree_add_debug_text(proto_tree *tree, const char *format, ...)
|
|
|
|
__attribute__((format (printf, 2, 3)));
|
|
|
|
#else
|
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 *
|
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
|
|
|
proto_tree_add_debug_text(proto_tree *tree, const char *format, ...);
|
|
|
|
#endif
|
|
|
|
|
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);
|
|
|
|
|
2001-12-18 19:09:08 +00:00
|
|
|
extern void
|
|
|
|
proto_tree_set_visible(proto_tree *tree, gboolean visible);
|
|
|
|
|
1999-08-26 07:01:44 +00:00
|
|
|
/* Returns number of items (protocols or header fields) registered. */
|
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
|
|
|
|
1999-11-11 16:20:25 +00:00
|
|
|
/* Returns char* to name for item # n (0-indexed) */
|
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
|
|
|
|
1999-08-26 07:01:44 +00:00
|
|
|
/* Returns char* to abbrev for item # n (0-indexed) */
|
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
|
|
|
|
2000-04-03 09:24:12 +00:00
|
|
|
/* get the header field information based upon a field or protocol id */
|
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
|
|
|
|
2002-04-18 20:19:10 +00:00
|
|
|
/* get the header field information based upon a field name */
|
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
|
|
|
|
1999-08-26 07:01:44 +00:00
|
|
|
/* Returns enum ftenum for item # n */
|
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
|
|
|
|
|
|
|
/* Returns parent protocol for item # n.
|
|
|
|
* Returns -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
|
|
|
|
|
|
|
/* Is item #n 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 gboolean proto_registrar_is_protocol(int n);
|
1999-08-26 07:01:44 +00:00
|
|
|
|
2003-11-16 23:17:27 +00:00
|
|
|
/* Is protocol's decoding enabled ? */
|
|
|
|
extern gboolean proto_is_protocol_enabled(protocol_t *protocol);
|
2001-01-03 06:56:03 +00:00
|
|
|
|
|
|
|
/* Can item #n decoding be disabled? */
|
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_can_disable_protocol(int proto_id);
|
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
|
|
|
|
2003-11-16 23:17:27 +00:00
|
|
|
/* Given a protocol's "protocol_t", return its proto_id */
|
|
|
|
extern int proto_get_id(protocol_t *protocol);
|
|
|
|
|
|
|
|
/* Given a protocol's filter_name, return its 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
|
|
|
|
2003-11-16 23:17:27 +00:00
|
|
|
/* Given a protocol's item number, find the "protocol_t" structure for it */
|
|
|
|
extern protocol_t *find_protocol_by_id(int proto_id);
|
|
|
|
|
2001-01-03 06:56:03 +00:00
|
|
|
/* Given a protocol's item number, return its 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_name(int n);
|
2001-01-03 06:56:03 +00:00
|
|
|
|
2003-11-16 23:17:27 +00:00
|
|
|
/* Given a protocol's "protocol_t", return its short name. */
|
|
|
|
extern char *proto_get_protocol_short_name(protocol_t *protocol);
|
2001-01-03 06:56:03 +00:00
|
|
|
|
|
|
|
/* Given a protocol's item number, 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
|
|
|
|
|
|
|
/* Enable / Disable 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
|
|
|
|
|
|
|
/* Disable disabling of 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_cant_disable(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
|
|
|
|
1999-10-12 04:21:13 +00:00
|
|
|
/* Get length of registered field according to field type.
|
|
|
|
* 0 means undeterminable at registration time.
|
|
|
|
* -1 means unknown field */
|
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 gint proto_registrar_get_length(int n);
|
1999-10-12 04:21:13 +00:00
|
|
|
|
1999-08-29 04:06:43 +00:00
|
|
|
/* Checks for existence any protocol or field within a tree.
|
2000-07-22 15:58:54 +00:00
|
|
|
* "Protocols" are assumed to be a child of the [empty] root node.
|
1999-08-29 04:06:43 +00:00
|
|
|
* TRUE = found, FALSE = not found */
|
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
|
2001-12-07 03:39:26 +00:00
|
|
|
* tree. */
|
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
|
|
|
|
2002-05-14 10:15:12 +00:00
|
|
|
/* Dumps a glossary of the protocol registrations to STDOUT */
|
|
|
|
extern void proto_registrar_dump_protocols(void);
|
|
|
|
|
1999-07-15 15:33:52 +00:00
|
|
|
/* Dumps a glossary of the protocol and field registrations to STDOUT */
|
2002-05-14 10:15:12 +00:00
|
|
|
extern void proto_registrar_dump_fields(void);
|
1999-07-15 15:33:52 +00:00
|
|
|
|
1999-11-16 11:44:20 +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
|
2002-04-01 02:00:53 +00:00
|
|
|
an item of that type are to be expanded. */
|
1999-11-16 11:44:20 +00:00
|
|
|
extern gboolean *tree_is_expanded;
|
|
|
|
|
|
|
|
/* Number of elements in that array. */
|
|
|
|
extern int num_tree_types;
|
|
|
|
|
2000-07-22 15:58:54 +00:00
|
|
|
/* glib doesn't have g_ptr_array_len of all things!*/
|
|
|
|
#ifndef g_ptr_array_len
|
|
|
|
#define g_ptr_array_len(a) ((a)->len)
|
|
|
|
#endif
|
|
|
|
|
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);
|
|
|
|
|
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"
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* Returns 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
|
|
|
|
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
|
|
|
|
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 */
|