From Michael Mann via https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6377, with...

[obnox/wireshark/wip.git] / doc / README.developer

diff --git a/doc/README.developer b/doc/README.developer
index 4c61d3b37499c1a5231a45033cb836004fa76982..6cb335e02f5584be99ae094539e0cc1b779d9944 100644 (file)
--- a/doc/README.developer
+++ b/doc/README.developer
@@ -1325,11 +1325,12 @@ with a lifetime of the current capture session. You do not need to
 free() this buffer, it will happen automatically once the a new capture or
 file is opened.
 
-tvb_fake_unicode() has been superceded by tvb_get_unicode_string(), which
+tvb_fake_unicode() has been superseded by tvb_get_unicode_string(), which
 properly handles Unicode (UTF-16) strings by converting them to UTF-8.
 
-tvb_get_ephemeral_faked_unicode() has been superceded by tvb_get_ephemeral_string(), which properly handles Unicode (UTF-16) strings by converting them
-to UTF-8.
+tvb_get_ephemeral_faked_unicode() has been superseded by
+tvb_get_ephemeral_string(), which properly handles Unicode (UTF-16) strings by
+converting them to UTF-8.
 
 Byte Array Accessors:
 
@@ -1877,15 +1878,15 @@ It requires a value_string as input.
 If all of a contiguous range of values from min to max are present in the array
 the value will be used as as a direct index into a value_string array.
 
-If the values in the array are not contiguous (ie: there are "gaps"), but are in assending order
-a binary search will be used.
+If the values in the array are not contiguous (ie: there are "gaps"), but are
+in assending order a binary search will be used.
 
-Note: "gaps" in a value_string array can be filled with "empty" entries eg: {value, "Unknown"} so that
-direct access to the array is is possible.
+Note: "gaps" in a value_string array can be filled with "empty" entries eg:
+{value, "Unknown"} so that direct access to the array is is possible.
 
-The init macro (see below) will perform a check on the value string
-the first time it is used to determine which search algorithm fits and fall back to a linear search
-if the value_string does not meet the criteria above.
+The init macro (see below) will perform a check on the value string the first
+time it is used to determine which search algorithm fits and fall back to a
+linear search if the value_string does not meet the criteria above.
 
 Use this macro to initialise the extended value_string at comile time:
 
@@ -1896,9 +1897,9 @@ Extended value strings can be created at runtime by calling
                         <total number of entries in the value_string_array>, /* include {0, NULL} entry */
                         <value_string_name>);
 
-For hf[] array FT_(U)INT* fields that need a 'valstringname_ext' struct, the 'strings' field
-would be set to '&valstringname_ext)'. Furthermore, 'display' field must be
-ORed with 'BASE_EXT_STRING' (e.g. BASE_DEC|BASE_EXT_STRING).
+For hf[] array FT_(U)INT* fields that need a 'valstringname_ext' struct, the
+'strings' field would be set to '&valstringname_ext)'. Furthermore, 'display'
+field must be ORed with 'BASE_EXT_STRING' (e.g. BASE_DEC|BASE_EXT_STRING).
 
 
 -- Ranges
@@ -2335,14 +2336,14 @@ proto_register_*() function) and a value.  The value will be fetched
 from the tvbuff by proto_tree_add_item(), based on the type of the field
 and the encoding of the value as specified by the "encoding" argument.
 
-For protocols, FT_NONE fields, FT_BYTES fields fields, FT_IPv6
-fields, FT_IPXNET fields, and FT_OID fields, the encoding is not
-relevant; the 'encoding' argument should be ENC_NA (Not Applicable).
+For FT_NONE, FT_BYTES, FT_ETHER, FT_IPv6, FT_IPXNET, FT_OID fields,
+and 'protocol' fields the encoding is not relevant; the 'encoding'
+argument should be ENC_NA (Not Applicable).
 
-For integral, floating-point, Boolean, and FT_GUID, FT_EUI64 fields, the encoding
-specifies the byte order of the value; the 'encoding' argument should be
-is ENC_LITTLE_ENDIAN if the value is little-endian and ENC_BIG_ENDIAN if
-it is big-endian.
+For integral, floating-point, Boolean, FT_GUID, and FT_EUI64 fields,
+the encoding specifies the byte order of the value; the 'encoding'
+argument should be is ENC_LITTLE_ENDIAN if the value is little-endian
+and ENC_BIG_ENDIAN if it is big-endian.
 
 For FT_IPv4 fields, the encoding also specifies the byte order of the
 value.  In almost all cases, the encoding is in network byte order,
@@ -2354,9 +2355,9 @@ For string fields, the encoding specifies the character set used for the
 string and the way individual code points in that character set are
 encoded.  For FT_UINT_STRING fields, the byte order of the count must be
 specified; when support for UTF-16 encoding is added, the byte order of
-the encoding will also have to be specified.  In other cases, either
-ENC_NA, ENC_BIG_ENDIAN, or ENC_LITTLE_ENDIAN can be specified.  The
-character encodings that are currently supported are:
+the encoding will also have to be specified.  In other cases, ENC_NA
+should be used.  The character encodings that are currently
+supported are:
 
        ENC_UTF_8 - UTF-8
        ENC_ASCII - ASCII (currently treated as UTF-8; in the future,