1999-07-07 22:52:57 +00:00
|
|
|
/* proto.h
|
|
|
|
* Definitions for protocol display
|
|
|
|
*
|
2002-04-01 02:00:53 +00:00
|
|
|
* $Id: proto.h,v 1.29 2002/04/01 02:00:52 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
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*
|
|
|
|
* 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
|
|
|
|
|
1999-07-13 02:53:26 +00:00
|
|
|
#ifdef HAVE_WINSOCK_H
|
1999-09-12 14:34:36 +00:00
|
|
|
# include <winsock.h>
|
1999-07-13 02:53:26 +00:00
|
|
|
#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-02-05 22:10:20 +00:00
|
|
|
#define VALS(x) (struct _value_string*)(x)
|
1999-07-07 22:52:57 +00:00
|
|
|
|
1999-10-12 06:21:15 +00:00
|
|
|
/* ... and similarly, */
|
|
|
|
#define TFS(x) (struct true_false_string*)(x)
|
1999-07-07 22:52:57 +00:00
|
|
|
|
2001-11-26 05:13:14 +00:00
|
|
|
/* check protocol activation */
|
|
|
|
#define CHECK_DISPLAY_AS_X(x_handle,index, tvb, pinfo, tree) { \
|
|
|
|
if (!proto_is_protocol_enabled(index)) { \
|
|
|
|
call_dissector(x_handle,tvb, pinfo, tree); \
|
|
|
|
return; \
|
|
|
|
} \
|
|
|
|
}
|
|
|
|
|
1999-10-12 06:21:15 +00:00
|
|
|
enum {
|
|
|
|
BASE_NONE,
|
|
|
|
BASE_DEC,
|
|
|
|
BASE_HEX,
|
|
|
|
BASE_OCT,
|
|
|
|
BASE_BIN
|
|
|
|
};
|
|
|
|
|
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 */
|
1999-10-12 06:21:15 +00:00
|
|
|
void *strings; /* val_string or true_false_string */
|
|
|
|
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;
|
|
|
|
|
|
|
|
|
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 {
|
2001-02-01 20:21:25 +00:00
|
|
|
header_field_info *hfinfo;
|
1999-07-07 22:52:57 +00:00
|
|
|
gint start;
|
|
|
|
gint length;
|
|
|
|
gint tree_type; /* ETT_* */
|
|
|
|
char *representation; /* for GUI tree */
|
|
|
|
int visible;
|
2001-02-01 20:21:25 +00:00
|
|
|
fvalue_t *value;
|
2002-02-18 01:08:44 +00:00
|
|
|
tvbuff_t *ds_tvb; /* data source tvbuff */
|
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;
|
|
|
|
|
|
|
|
/* Each GNode (proto_tree, proto_item) points to one of
|
|
|
|
* these. */
|
|
|
|
typedef struct {
|
|
|
|
field_info *finfo;
|
|
|
|
tree_data_t *tree_data;
|
|
|
|
} proto_node;
|
|
|
|
|
|
|
|
typedef GNode proto_tree;
|
|
|
|
typedef GNode proto_item;
|
|
|
|
|
|
|
|
/* Retrieve the proto_node from a GNode. */
|
|
|
|
#define GNODE_PNODE(t) ((proto_node*)((GNode*)(t))->data)
|
|
|
|
|
|
|
|
/* Retrieve the field_info from a proto_item */
|
|
|
|
#define PITEM_FINFO(t) (GNODE_PNODE(t)->finfo)
|
|
|
|
|
|
|
|
/* Retrieve the tree_data_t from a proto_tree */
|
|
|
|
#define PTREE_DATA(t) (GNODE_PNODE(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
|
|
|
|
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
|
|
|
|
2001-12-18 19:09:08 +00:00
|
|
|
/* Mark a field/protocol ID as "interesting". */
|
|
|
|
void
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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 */
|
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 header_field_info* proto_registrar_get_nth(int hfindex);
|
2000-04-03 09:24:12 +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
|
|
|
|
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
|
|
|
/* Is item #n decoding enabled ? */
|
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_is_protocol_enabled(int proto_id);
|
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
|
|
|
|
|
|
|
/* Routines to use to iterate over the protocols; they return the item
|
|
|
|
* number of the protocol in question, 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);
|
2001-01-03 06:56:03 +00:00
|
|
|
|
2001-04-01 22:50:08 +00:00
|
|
|
/* Given a protocol's filter_name, return it's 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
|
|
|
|
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
|
|
|
|
|
|
|
/* Given a protocol's item number, return its short 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_short_name(int proto_id);
|
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
|
|
|
|
1999-07-15 15:33:52 +00:00
|
|
|
/* Dumps a glossary of the protocol and field registrations to STDOUT */
|
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_registrar_dump(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);
|
|
|
|
|
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
|
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
|
|
|
proto_can_match_selected(field_info *finfo);
|
|
|
|
|
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*
|
2001-02-01 20:21:25 +00:00
|
|
|
proto_alloc_dfilter_string(field_info *finfo, guint8 *pd);
|
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 */
|