path: root/doc/README.display_filter
diff options
authorJörg Mayer <jmayer@loplof.de>2012-07-26 14:38:36 +0000
committerJörg Mayer <jmayer@loplof.de>2012-07-26 14:38:36 +0000
commita1f2ea8726a35f97dc33438c3d2a679a21a05fea (patch)
treeece551124ed0daffede85a3fc7e0805deab44e39 /doc/README.display_filter
parent1df71749464179645ce840c88e785e07b30d3692 (diff)
Fix some percieved typos
svn path=/trunk/; revision=44045
Diffstat (limited to 'doc/README.display_filter')
1 files changed, 9 insertions, 9 deletions
diff --git a/doc/README.display_filter b/doc/README.display_filter
index ec53a609e6..9293268ec7 100644
--- a/doc/README.display_filter
+++ b/doc/README.display_filter
@@ -17,7 +17,7 @@ For example, this is the definition of the ip.proto field from packet-ip.c:
This definition says that "ip.proto" is the display-filter name for
this field, and that its field-type is FT_UINT8.
-For the diplay filter system has 3 major parts to it:
+The diplay filter system has 3 major parts to it:
1. A type system (field types, or "ftypes")
2. A parser, to convert a user's query to an internal representation
@@ -53,7 +53,7 @@ enum ftenum {
It also provides the defintion of fvalue_t, the struct that holds the *value*
-that corresponds to the type. each proto_item (proto_node) holds an fvalue_t
+that corresponds to the type. Each proto_item (proto_node) holds an fvalue_t
due to having a field_info struct (defined in proto.h).
The fvalue_t is mostly just a gigantic union of possible C-language types
@@ -100,13 +100,13 @@ FT_UINT32, etc.
The ftype_t struct defines the things needed for the ftype:
- * it's ftenum value
+ * its ftenum value
* a string representation of the FT name ("FT_UINT8")
* how much data it consumes in the packet
* how to store that value in an fvalue_t: new(), free(),
various value-related funtions
* how to compare that value against another
- * how to slice that value (strings an byte ranges can be sliced)
+ * how to slice that value (strings and byte ranges can be sliced)
Using an fvalue_t
@@ -139,8 +139,8 @@ There are four phases to parsing a users's request:
The dfilter_compile() function, in epan/dfilter/dfilter.c,
runs these 4 phases. The end result is a dfwork_t object (dfw), that
-can be passe dto dfilter_apply() to actually run the display filter
-against a set of proto_tree's.
+can be passed to dfilter_apply() to actually run the display filter
+against a set of proto_trees.
Scanning the display filter string
@@ -149,7 +149,7 @@ epan/dfilter/scanner.l is the lex scanner for finding keywords
in the user's display filter string.
It's operation is simple. It finds the special punction and comparison
-operators ("==", "!=", "eq", "ne", etc.), it finds slice operaions
+operators ("==", "!=", "eq", "ne", etc.), it finds slice operations
( "[0:1]" ), quoted strings, IP addresses, numbers, and any other "special"
keywords or string types.
@@ -176,7 +176,7 @@ much easier to read than its bison counterpart would be,
thanks to lemon's feature of being able to name fields, rather
then using numbers ($1, $2, etc.)
-The lemon tool is located in tools/lemon in the wireshark
+The lemon tool is located in tools/lemon in the Wireshark
An on-line introduction to lemon is available at:
@@ -259,7 +259,7 @@ integer, float, IPv4 address, etc.)
The semcheck code also makes adjustments to the syntax tree
when it needs to. The parser sometimes stores raw, unparsed strings
-in the syntax tree, and semcheck has toto convert them to
+in the syntax tree, and semcheck has to convert them to
certain types. For example, the display filter may contain
a value_string string (the "enum" type that protocols can use
to define the possible textual descriptions of numeric fields), and