Add missing comments in syntax description for -z expert
[obnox/wireshark/wip.git] / doc / README.developer
index 2295af5e7725d6c5f1be50eb4e9dfa7afe8ae2f4..6cb335e02f5584be99ae094539e0cc1b779d9944 100644 (file)
@@ -1127,7 +1127,7 @@ FIELDABBREV       The abbreviated name for the header field. (NO SPACES)
 FIELDTYPE      FT_NONE, FT_BOOLEAN, FT_UINT8, FT_UINT16, FT_UINT24,
                FT_UINT32, FT_UINT64, FT_INT8, FT_INT16, FT_INT24, FT_INT32,
                FT_INT64, FT_FLOAT, FT_DOUBLE, FT_ABSOLUTE_TIME,
-               FT_RELATIVE_TIME, FT_STRING, FT_STRINGZ, FT_EBCDIC, FT_EUI64
+               FT_RELATIVE_TIME, FT_STRING, FT_STRINGZ, FT_EUI64,
                FT_UINT_STRING, FT_ETHER, FT_BYTES, FT_UINT_BYTES, FT_IPv4,
                FT_IPv6, FT_IPXNET, FT_FRAMENUM, FT_PROTOCOL, FT_GUID, FT_OID
 FIELDDISPLAY   For FT_UINT{8,16,24,32,64} and FT_INT{8,16,24,32,64):
@@ -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:
 
@@ -1730,23 +1731,6 @@ The type of value this field holds. The current field types are:
                                displayed as the date, followed by the time, as
                                hours, minutes, and seconds with 9 digits after
                                the decimal point.
-
-                               Two absolute time encodings may be specified
-                               with proto_tree_add_item():
-
-                               ENC_TIME_TIMESPEC: Seconds (4 bytes) and
-                               nanoseconds (4 bytes) of time since January 1,
-                               1970, midnight UTC.
-
-                               ENC_TIME_NTP: NTP timestamps are represented as
-                               a 64-bit unsigned fixed-point number, in seconds
-                               relative to 0h on 1 January 1900. The integer
-                               part is in the first 32 bits and the fraction
-                               part in the last 32 bits.
-
-                               The encoding must be logically ORed with
-                               ENC_BIG_ENDIAN or ENC_LITTLE_ENDIAN as
-                               appropriate.
        FT_RELATIVE_TIME        Seconds (4 bytes) and nanoseconds (4 bytes)
                                of time relative to an arbitrary time.
                                displayed as seconds and 9 digits
@@ -1762,10 +1746,6 @@ The type of value this field holds. The current field types are:
                                However if the length given in the call
                                is -1, then the length used is that
                                returned by calling tvb_strsize().
-       FT_EBCDIC               A string of characters, not necessarily
-                               NUL-terminated, but possibly NUL-padded.
-                               The data from the packet is converted from
-                               EBCDIC to ASCII before displaying to the user.
        FT_UINT_STRING          A counted string of characters, consisting
                                of a count (represented as an integral value,
                                of width given in the proto_tree_add_item()
@@ -1898,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:
 
@@ -1917,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
@@ -2354,13 +2334,52 @@ proto_tree_add_item is used when you wish to do no special formatting.
 The item added to the GUI tree will contain the name (as passed in the
 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, for integral and Boolean fields, the byte order of the value; the
-byte order, for items for which that's relevant, is specified by the
-'encoding' argument, which is ENC_LITTLE_ENDIAN if the value is
-little-endian and ENC_BIG_ENDIAN if it is big-endian.  If the byte order
-is not relevant, use ENC_NA (Not Applicable).  For some field types,
-additional encoding information, such as the character encoding for
-character strings, are supported.
+and the encoding of the value as specified by the "encoding" argument.
+
+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, 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,
+hence big-endian, but in at least one protocol dissected by Wireshark,
+at least one IPv4 address is byte-swapped, so it's in little-endian
+order.
+
+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, 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,
+               all bytes with the 8th bit set will be treated as
+               errors)
+       ENC_EBCDIC - EBCDIC
+
+Other encodings will be added in the future.
+
+For FT_ABSOLUTE_TIME fields, the encoding specifies the form in which
+the time stamp is specified, as well as its byte order.  The time stamp
+encodings that are curretly supported are:
+
+       ENC_TIME_TIMESPEC - seconds (4 bytes) and nanoseconds (4 bytes)
+               of time since January 1, 1970, midnight UTC.
+
+       ENC_TIME_NTP - an NTP timestamp, represented as a 64-bit
+               unsigned fixed-point number, in seconds relative to 0h
+               on 1 January 1900.  The integer part is in the first 32
+               bits and the fraction part in the last 32 bits.
+
+For other types, there is no support for proto_tree_add_item().
 
 Now that definitions of fields have detailed information about bitfield
 fields, you can use proto_tree_add_item() with no extra processing to
@@ -3856,7 +3875,7 @@ static hf_register_info hf[] = {
    };
 
 /**
-*   Dissect a buffer containing C strings.
+*   Dissect a buffer containing ASCII C strings.
 *
 *   @param  tvb     The buffer to dissect.
 *   @param  pinfo   Packet Info.
@@ -3882,7 +3901,7 @@ static void dissect_cstr(tvbuff_t * tvb, packet_info * pinfo, proto_tree * tree)
 
         if (tree) {
             proto_tree_add_item(tree, hf_cstring, tvb, offset, len,
-                               ENC_NA);
+                               ENC_ASCII|ENC_NA);
         }
         offset += (guint)len;
     }