aboutsummaryrefslogtreecommitdiffstats
path: root/doc
diff options
context:
space:
mode:
authorjake <jake@f5534014-38df-0310-8fa8-9805f1628bb7>2008-03-23 09:05:57 +0000
committerjake <jake@f5534014-38df-0310-8fa8-9805f1628bb7>2008-03-23 09:05:57 +0000
commit8f41871b528b849ffce0d1f4963195013d3da612 (patch)
treec1424153ae033fb2da8265217e40286a438db947 /doc
parentaf8d47f5390756087a1765a77e8b80715e1b4d69 (diff)
From William Pursell:
typos in documentation. git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@24719 f5534014-38df-0310-8fa8-9805f1628bb7
Diffstat (limited to 'doc')
-rw-r--r--doc/README.developer34
1 files changed, 17 insertions, 17 deletions
diff --git a/doc/README.developer b/doc/README.developer
index fbea07c725..70870b05c1 100644
--- a/doc/README.developer
+++ b/doc/README.developer
@@ -1172,7 +1172,7 @@ guint8* tvb_get_ptr(tvbuff_t*, gint offset, gint length);
The reason that tvb_get_ptr() might have to allocate a copy of its data
only occurs with TVBUFF_COMPOSITES, data that spans multiple tvbuffers.
-If the user requests a pointer to a range of bytes that spans the member
+If the user requests a pointer to a range of bytes that span the member
tvbuffs that make up the TVBUFF_COMPOSITE, the data will have to be
copied to another memory region to assure that all the bytes are
contiguous.
@@ -1346,7 +1346,7 @@ fence does not already exist.
1.5.9 The col_set_time function.
-The 'col_set_time' function takes a nstime value as it's third argument.
+The 'col_set_time' function takes an nstime value as its third argument.
This nstime value is a relative value and will be added as such to the
column. The fourth argument is the filtername holding this value. This
way, rightclicking on the column makes it possible to build a filter
@@ -1458,7 +1458,7 @@ Here is how the frame "protocol" is registered.
/* abbrev */ "frame" );
A header field is also registered with its name and abbreviation, but
-information about the its data type is needed. It helps to look at
+information about its data type is needed. It helps to look at
the header_field_info struct to see what information is expected:
struct header_field_info {
@@ -1571,7 +1571,7 @@ to represent the number.
display
-------
The display field has a couple of overloaded uses. This is unfortunate,
-but since we're C as an application programming language, this sometimes
+but since we're using C as an application programming language, this sometimes
makes for cleaner programs. Right now I still think that overloading
this variable was okay.
@@ -1587,7 +1587,7 @@ are:
BASE_DEC, BASE_HEX, and BASE_OCT are decimal, hexadecimal, and octal,
respectively. BASE_DEC_HEX and BASE_HEX_DEC display value in two bases
-(the 1st representation followed by the 2nd in parenthesis)
+(the 1st representation followed by the 2nd in parenthesis).
For FT_BOOLEAN fields that are also bitfields, 'display' is used to tell
the proto_tree how wide the parent bitfield is. With integers this is
@@ -2141,7 +2141,7 @@ won't be seen unless the user opens the subtree--but they can be found if the
user wants.
NOTE, too, that all of the proto_tree_add_*_hidden() APIs are deprecated:
-instead of using them, use add the item using proto_tree_add_item() and then
+instead of using them, add the item using proto_tree_add_item() and then
make it hidden using PROTO_ITEM_SET_HIDDEN().
One use for hidden fields (which would be better implemented using visible
@@ -2411,11 +2411,11 @@ after the "type" and "value" fields have been extracted and dissected.
<label> would be a label giving what information about the subtree is
available without dissecting any of the data in the subtree.
-Note that an exception might thrown when trying to extract the values of
+Note that an exception might be thrown when trying to extract the values of
the items used to set the label, if not all the bytes of the item are
available. Thus, one should create the item with text that is as
meaningful as possible, and set it or append additional information to
-it as the values needed to supply that information is extracted.
+it as the values needed to supply that information are extracted.
proto_tree_add_text_valist()
----------------------------
@@ -2656,7 +2656,7 @@ it is wise to check the relevant header and source files for additional details.
2.2 Following "conversations".
-In wireshark a conversation is defined as a series of data packet between two
+In wireshark a conversation is defined as a series of data packets between two
address:port combinations. A conversation is not sensitive to the direction of
the packet. The same conversation will be returned for a packet bound from
ServerA:1000 to ClientA:2000 and the packet from ClientA:2000 to ServerA:1000.
@@ -2668,7 +2668,7 @@ conversation_get_proto_data, and conversation_delete_proto_data.
2.2.1 The conversation_init function.
-This is an internal routine for the conversation code. As such the you
+This is an internal routine for the conversation code. As such you
will not have to call this routine. Just be aware that this routine is
called at the start of each capture and before the packets are filtered
with a display filter. The routine will destroy all stored
@@ -2839,7 +2839,7 @@ typically in the proto_register_XXXX portion of a dissector.
2.2.7 Using timestamps relative to the conversation
-There is a framework to calculate timestams relative to the start of the
+There is a framework to calculate timestamps relative to the start of the
conversation. First of all the timestamp of the first packet that has been
seen in the conversation must be kept in the protocol data to be able
to calculate the timestamp of the current packet relative to the start
@@ -2870,11 +2870,11 @@ COL_DELTA_CONV_TIME,/* Delta time to last frame in conversation */
Last but not least, there MUST be a preference in each dissector that
uses conversation timestamps that makes it possible to enable and
-dissable the calculation of conversation timestamps. The main argument
+disable the calculation of conversation timestamps. The main argument
for this is that a higher level conversation is able to overwrite
the values of lowel level conversations in these two columns. Being
able to actively select which protocols may overwrite the conversation
-timestamp columns give the user the power to control these columns.
+timestamp columns gives the user the power to control these columns.
(A second reason is that conversation timestamps use the per packet
data structure which uses additional memory, which should be avoided
if these timestamps are not needed)
@@ -2980,7 +2980,7 @@ my_proto = proto_register_protocol("My Protocol", "My Protocol", "my_proto");
Sometimes a dissector has determined that a new conversation is needed that
starts at a specific frame number, when a capture session encompasses multiple
conversation that reuse the same src/dest ip/port pairs. You can use the
-compare the conversation->setup_frame returned by find_conversation with
+conversation->setup_frame returned by find_conversation with
pinfo->fd->num to determine whether or not there already exists a conversation
that starts at the specific frame number.
@@ -3071,7 +3071,7 @@ the dissection routine.
Before we create these conversations or assign a dissector to them we should
first check that the conversation does not already exist and if it exists
whether it is registered to our protocol or not.
-We should do this because is uncommon but it does happen that multiple
+We should do this because it is uncommon but it does happen that multiple
different protocols can use the same socketpair during different stages of
an application cycle. By keeping track of the frame number a conversation
was started in wireshark can still tell these different protocols apart.
@@ -3166,7 +3166,7 @@ the same socketpair.
(See packet-tftp.c and packet-snmp.c for examples of this)
There are two support routines that will allow the second port and/or
-address to be set latter.
+address to be set later.
conversation_set_port2( conversation_t *conv, guint32 port);
conversation_set_addr2( conversation_t *conv, address addr);
@@ -3174,7 +3174,7 @@ conversation_set_addr2( conversation_t *conv, address addr);
These routines will change the second address or port for the
conversation. So, the server port conversation will be converted into a
more complete conversation definition. Don't use these routines if you
-want create a conversation between the server and client and retain the
+want to create a conversation between the server and client and retain the
server port definition, you must create a new conversation.