I'm missing something or the MSVC++ code analyzer doesn't realize that
in
if (XXX)
dereference XXX
will not dereference XXX if it's null - maybe "if (XXX != NULL)" will do
the trick (if so, the code analyzer is buggy, because "if (XXX !=
NULL)", "if (XXX != 0)", and "if (XXX)" mean the exact same thing if XXX
is a pointer-valued expression, really, truly, even if a null pointer
isn't represented as all zero bits or if it's wider than an int).
Clean up indentation.
svn path=/trunk/; revision=35973
GetModuleHandle() could return a null pointer, which is possible,
although if it returns one when handed "kernel32.dll", you have bigger
problems...).
Add some comments.
svn path=/trunk/; revision=35972
somewhat redundant, as items aren't displayed if they're not known, but
it can make it a little clearer to people who aren't familiar with the
gory details of radiotap (which people just looking at network traffic
might not be).
Clean up some capitalization of field names.
svn path=/trunk/; revision=35968
There's no need to pass the result of tvb_get_ptr() as the 'value' in
proto_tree_add_*(): just use proto_tree_add_item().
svn path=/trunk/; revision=35962
the functions take a pointer to a TVB and an offset rather than (generally)
a pointer into a TVB.
Use NULL as the value_ptr in proto_tree_add_bytes_format() since the bytes are
coming straight from the TVB anyway.
Remove unnecessary include file.
svn path=/trunk/; revision=35958
either the VC++ analyzer can't determine that or it *can*, in fact,
happen). Pick an error code that's not too far off.
svn path=/trunk/; revision=35957
** (tshark.exe:4392): WARNING **: Dissector bug, protocol GSM BSSMAP, in packet
194520: More than 1000000 items in the tree -- possible infinite loop
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5688
svn path=/trunk/; revision=35939
P2P_DIR_SENT or P2P_DIR_RECV - it might be unknown.
Use some #defines for SDP data element IDs, and rename the routine that
gets data elements tor reflect what it does.
svn path=/trunk/; revision=35934
pseudo-header, and hence there's no direction indication. Don't set
pinfo->p2p_dir for it. Use WTAP_ENCAP_BLUETOOTH_H4_WITH_PHDR, not
WTAP_ENCAP_BLUETOOTH_H4, for capture files where we have the direction.
Don't assume pinfo->p2p_dir is either P2P_DIR_SENT or P2P_DIR_RECV when
setting the info column in various Bluetooth dissectors; it might be
unknown.
In the HCI H4 dissector, put the direction into the info column
regardless of whether we have a type match or not; the dissectors for
HCI packet types appear to assume it's been set (as they put a blank at
the beginning of the stuff they append to the direction).
svn path=/trunk/; revision=35933
in another list: convert the 2nd list to a hash. This speeds checking for ett_
variables up considerably.
Store the pattern to match ett_ variable names in a variable (since it's used 3
times).
Only match ett_ variable declarations that start on their own line (hopefully to
speed things up a bit).
svn path=/trunk/; revision=35929
Anders Broman