Fix a typo.

Wrap text to 80 columns.

Add myself to the authors list (e.g. for the portability section).

svn path=/trunk/; revision=8108

1 files changed, 32 insertions, 27 deletions

diff --git a/doc/README.developer b/doc/README.developer
index 17395b40d7..63ae48b00d 100644
--- a/doc/README.developer
+++ b/doc/README.developer
@@ -1,4 +1,4 @@
-$Id: README.developer,v 1.77 2003/07/25 03:43:59 gram Exp $
+$Id: README.developer,v 1.78 2003/07/30 23:18:55 guy Exp $
 
 This file is a HOWTO for Ethereal developers. It describes how to start coding
 a Ethereal protocol dissector and the use some of the important functions and
@@ -208,7 +208,7 @@ code inside
 
 is needed only if you are using the "snprintf()" function.
 
-The "$Id: README.developer,v 1.77 2003/07/25 03:43:59 gram Exp $"
+The "$Id: README.developer,v 1.78 2003/07/30 23:18:55 guy Exp $"
 in the comment will be updated by CVS when the file is
 checked in; it will allow the RCS "ident" command to report which
 version of the file is currently checked out.
@@ -218,7 +218,7 @@ version of the file is currently checked out.
  * Routines for PROTONAME dissection
  * Copyright 2000, YOUR_NAME <YOUR_EMAIL_ADDRESS>
  *
- * $Id: README.developer,v 1.77 2003/07/25 03:43:59 gram Exp $
+ * $Id: README.developer,v 1.78 2003/07/30 23:18:55 guy Exp $
  *
  * Ethereal - Network traffic analyzer
  * By Gerald Combs <gerald@ethereal.com>
@@ -2147,41 +2147,45 @@ epan/proto.c   - proto_tree-related routines
 
 5.1 Parsing text
 
-The scanner/parser pair read the string representing the display filter and
-convert it into a very simple syntax tree. The syntax tree is very simple in that
-it is possible that many of the nodes contain unparsed chunks of text from the display
-filter.
+The scanner/parser pair read the string representing the display filter
+and convert it into a very simple syntax tree.  The syntax tree is very
+simple in that it is possible that many of the nodes contain unparsed
+chunks of text from the display filter.
 
 5.1 Enhancing the syntax tree.
 
-The semantics of the simple syntax tree are checked to make sure that the fields
-that are being compared are being compared to appropriate values. For example,
-if a field is an integer, it can't be compared to a string, unless a value_string
-has been defined for that field.
+The semantics of the simple syntax tree are checked to make sure that
+the fields that are being compared are being compared to appropriate
+values.  For example, if a field is an integer, it can't be compared to
+a string, unless a value_string has been defined for that field.
 
-During the process of checking the semantics, the simple syntax tree is fleshed out
-and no longer contains nodes with unparsed information. The syntax tree is no
-longer in its simple form, but in its complete form.
+During the process of checking the semantics, the simple syntax tree is
+fleshed out and no longer contains nodes with unparsed information.  The
+syntax tree is no longer in its simple form, but in its complete form.
 
 5.2 Converting to DFVM bytecode
 
-The syntax tree is analyzed to create a sequence of bytecodes in the "DFVM" language.
-"DFVM" stands for Display Filter Virtual Machine. The DFVM is similar in spirit, but
-not in definition, to the BPF VM that libpcap uses to analyze packets.
+The syntax tree is analyzed to create a sequence of bytecodes in the
+"DFVM" language.  "DFVM" stands for Display Filter Virtual Machine.  The
+DFVM is similar in spirit, but not in definition, to the BPF VM that
+libpcap uses to analyze packets.
 
-A virtual bytecode is created and used so that the actual process of filtering packets
-will be fast.  That is, it should be faster to process a list of VM bytecodes than
-to attempt to filter packets directly from the syntax tree.  (heh... no measurement
-has been made to support this supposition)
+A virtual bytecode is created and used so that the actual process of
+filtering packets will be fast.  That is, it should be faster to process
+a list of VM bytecodes than to attempt to filter packets directly from
+the syntax tree.  (heh...  no measurement has been made to support this
+supposition)
 
 5.3 Filtering
 
-Once the DFVM bytecode has been produced, its a simple matter of running the
-DFVM engine against the proto_tree from the packet dissection, using the DFVM bytecodes
-as instructions. If the DFVM bytecode is known before packet dissection occurs,
-the proto_tree-related code can be "primed" to store away pointers to field_info
-structures that are interesting to the display filter. This makes lookup of those
-field_info structures during the filtering process faster.
+Once the DFVM bytecode has been produced, it's a simple matter of
+running the DFVM engine against the proto_tree from the packet
+dissection, using the DFVM bytecodes as instructions.  If the DFVM
+bytecode is known before packet dissection occurs, the
+proto_tree-related code can be "primed" to store away pointers to
+field_info structures that are interesting to the display filter.  This
+makes lookup of those field_info structures during the filtering process
+faster.
 
 
 6.0 Adding new capabilities.
@@ -2195,3 +2199,4 @@ Jeff Foster <jfoste@woodward.com>
 Olivier Abad <oabad@cybercable.fr>
 Laurent Deniel <laurent.deniel@free.fr>
 Gerald Combs <gerald@ethereal.com>
+Guy Harris <guy@alum.mit.edu>