tvb_get_unicode_string(). If there's an indication that the encoding is
UCS-2, use that, otherwise use UTF-16. (For example, "BMP" stands for
"Basic Multilingual Plane", which is the part of Unicode that can be
encoded in 16 bits, hence UCS-2.)
In the description of the "Use Heuristics for UDP" preference for the
XML dissector, note that it's not just trying to recognize XML in UCS-2,
it's trying to recognize XML in *big-endian* UCS-2.
svn path=/trunk/; revision=54245
(sort associated value_string arrays as needed);
- Use new VALUE_STRING_LIST mechanism/macros to
create enums and value_string arrays for:
WERR_errors, DOS_errors, SRV_errors, and HRD_errors;
- Declare certain global value_string arrays as static (local)
and use global extended value_strings to reference same;
(e.g., ms_coiuntry_codes value_string_array)
- Rename SMBE_... defs used in several different value_string arrays
to prevent potential name collisions:
( e.g., for SRV_errors: SMBE_... ==> SMBE_SRV_...)
Done for value_string arrays: DOS_errors, SRV_errors, HRD_errors;
- WERR_errors value_string array:
Note that WERR associated defs no longer exist in the latest samba doserr.h.
(The WERR_errors defs were originally generated from the samba doserr.h).
For now: WERR_errors kept as is.
- ToDo: Fix PIDL-generated dcerpc dissectors to use NT_errors_ext
and WERR_errors_ext extended value_strings.
- Add editor modelines to a few files.
- Make whitespace changes.
svn path=/trunk/; revision=53614
Now that "bytes consumed" can be determined, should tcp_dissect_pdus() take advantage of that?
Should tcp_dissect_pdus return length (bytes consumed)? There are many dissectors that just call tcp_dissect_pdus() then return tvb_length(tvb). Seems like that could all be rolled into one.
svn path=/trunk/; revision=53198
All "generated" source was manually modified (with the power of search/replace), but I believe the "source input" files have been adjusted (checked into revs 53098 and 53099) to reflect the necessary changes (with possible whitespace formatting differences).
The Microsoft compiler doesn't flag "unused function parameters", so I apologize in advance if I may have missed a few. The "dcerpc_info* di" parameter is used in almost every function.
svn path=/trunk/; revision=53100
request for implicit conversion from 'gpointer' to 'char *' not permitted
in C++ [-Werror=c++-compat]
and
enum conversion when passing argument 3 of 'krb5_crypto_init' is invalid
in C++ [-Werror=c++-compat]
svn path=/trunk/; revision=50108
epan/show_exception.c, as it's used outside
epan/dissectors/packet-frame.c. Update their callers to include
<epan/show_exception.h> to get their declaration.
Add a CATCH_NONFATAL_ERRORS macro that catches all exceptions that, if
there's more stuff in the packet to dissect after the dissector call
that threw the exception, doesn't mean you shouldn't go ahead and
dissect that stuff. Use it in all those cases, including ones where
BoundsError was inappropriately being caught (you want those passed up
to the top level, so that the packet is reported as having been cut
short in the capture process).
Add a CATCH_BOUNDS_ERRORS macro that catches all exceptions that
correspond to running past the end of the data for a tvbuff; use it
rather than explicitly catching those exceptions individually, and
rather than just catching all exceptions (the only place that
DissectorError should be caught, for example, is at the top level, so
dissector bugs show up in the protocol tree).
Don't catch and then immediately rethrow exceptions without doing
anything else; just let the exceptions go up to the final catcher.
Use show_exception() to report non-fatal errors, rather than doing it
yourself.
If a dissector is called from Lua, catch all non-fatal errors and use
show_exception() to report them rather than catching only
ReportedBoundsError and adding a proto_malformed item.
Don't catch exceptions when constructing a trailer tvbuff in
packet-ieee8023.c - just construct it after the payload has been
dissected, and let whatever exceptions that throws be handled at the top
level.
Avoid some TRY/CATCH/ENDTRY cases by using checks such as
tvb_bytes_exist() before even looking in the tvbuff.
svn path=/trunk/; revision=47924
tvbuff and runs to the end of the tvbuff? Let me count the ways....
Replace a bunch of different ways of doing that (some incorrect, in that
they're not properly handling tvbuffs where the captured and reported
lengths are different) with tvb_new_subset_remaining().
svn path=/trunk/; revision=47751
routine (prefs_register_directory_preference). Add PREF_FILENAME and
PREF_DIRNAME support to the Qt module preferences. Change a couple of
preferences to directory names.
Clean up some names and default settings.
svn path=/trunk/; revision=47573
In one case, define our own size for a string buffer
(instead of using a magic constant 'BUFSIZ');
In a few cases: do some whitespace, indentation & reformatting cleanup.
svn path=/trunk/; revision=42634
In some cases:
Use val_to_str_const() instead of val_to_str();
Reformat long lines;
Do some general whitespace changes.
svn path=/trunk/; revision=41587
Specifically: Replace FALSE|0 and TRUE|1 by ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN as
the encoding parameter for proto_tree_add_item() calls which directly reference
an item in hf[] which has a type of:
FT_BOOLEAN
FT_IPv4
FT_EUI64
FT_GUID
FT_UINT_STRING
Also: For type FT_ITv6 use ENC_NA. (This was missed in SVN #39260)
svn path=/trunk/; revision=39328
Specifically: Replace FALSE|0 and TRUE|1 by ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN as
the encoding parameter for proto_tree_add_item() calls which directly reference
an item in hf[] which has a type of:
FT_UINT8
FT_UINT16
FT_UINT24
FT_UINT32
FT_UINT64
FT_INT8
FT_INT16
FT_INT24
FT_INT32
FT_INT64
FT_FLOAT
FT_DOUBLE
svn path=/trunk/; revision=39288
FT_NONE
FT_BYTES
FT_IPV6
FT_IPXNET
FT_OID
Note: Encoding field set to ENC_NA only if the field was previously TRUE|FALSE|ENC_LITTLE_ENDIAN|ENC_BIG_ENDIAN
svn path=/trunk/; revision=39260
keys to have _uint in their names, to match the routines that handle
dissector tables with string keys. (Using _port can confuse people into
thinking they're intended solely for use with TCP/UDP/etc. ports when,
in fact, they work better for things such as Ethernet types, where the
binding of particular values to particular protocols are a lot
stronger.)
svn path=/trunk/; revision=35224