capture interfaces dialog code, *and* the code that calls it, under
HAVE_LIBPCAP.
Still more stuff to remove from the no-pcap UI, such as the Capture
menu, the capture filter in the main window, and the list of interfaces
in the main window.
svn path=/trunk/; revision=53582
an interface, don't destroy the default link-layer header type from the
list of types.
I.e., first get the type from the preference (which sets the type to -1
if there isn't a preference), and then loop through the list of types
and, if there was no value obtained from the preference (i.e., the type
is -1), set it to the first type in the list.
Also, don't bother with the link-layer header type from the global
default options, as a global (all-interface) link-layer header type
makes little sense, given that the list of link-layer header types for
an interface depends on the type of interface and hence may differ from
interface to interface.
Fixes bug 9473.
svn path=/trunk/; revision=53581
Comment out an unused variable definition;
Do some whitespace changes & several other minor changes;
Add editor modelines.
svn path=/trunk/; revision=53578
Use 'offset += 1' instead of 'offset++' for consistency;
Replace 32767 (as a mask) with 0x7FFF for clarity;
Remove some unneeded boilerplate comments;
Do whitespace changes.
svn path=/trunk/; revision=53577
and also DT1s. Update the preference text to reflect that.
(Don't change the actual preference name to avoid breaking backward
compatibility.)
svn path=/trunk/; revision=53576
Move value_string array definitions from .h to .c file
(value_string definitions should never be in a .h file);
Add XXX comments re value_string arrays containing
duplicate values [ptp_opcode_names & ptp_respcode_names];
Remove unneeded #includes (stdio.h, stdlib.h & string.h);
Remove some unneeded initializers;
Add editor modelines.
Do some whitespace & long-lines changes;
svn path=/trunk/; revision=53570
* Reuse sparkline from welcome
* Split settings in tab (!= GTK)
* No all feature work (Work In Progress...)
* ...
Comments (and review) are welcome !
svn path=/trunk/; revision=53563
Add an XXX comment noting that the 'ndps_error_types' array has a
number of duplicate values; Also note the commenting out of those
dups which would not have been found via a linear search in the
original unsorted array.
svn path=/trunk/; revision=53558
http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Code-Gen-Options.html#Code-Gen-Options
-ftrapv "generates traps for signed overflow on addition, subtraction,
multiplication operations." and -fwrapv "instructs the compiler to
assume that signed arithmetic overflow of addition, subtraction and
multiplication wraps around using twos-complement representation."
Those seem mutually-exclusive to me, and we probably want wrapping, not
traps, as there's probably a fair bit of code out there that explicitly
or implicitly assumes wrapping. (Actually, we really want to avoid
signed arithmetic for the cases that most matter, such as offsets and
lengths, but, unfortunately, we currently have API conventions that
allow negative values for lengths, either with -1 meaning "to the end"
or with negative values meaning "relative to the end".) In addition,
there seem to be some bugs complaining that -ftrapv doesn't always cause
traps on signed integer overflow.
We seem to be seeing crashes in Lemon on the Solaris buildbot subsequent
to adding -ftrapv; I don't know whether that's an overflow being
detected, a bug in the compiler, or something unrelated, especially
given that we're using Sun C, not GCC, on the Solaris buildbot.
However, we'll try removing -ftrapv, to see if it fixes the problem; the
MIT CSAIL paper in question wasn't really recommending all the GCC
options it mentioned (which, as noted, wouldn't make sense, as -ftrapv
and -fwrapv appear to be mutually-exclusive).
svn path=/trunk/; revision=53556
effort to figure out whether they *are* used (and there's no point in it
doing so - might as well just flag them preemptively).
pidl can't handle this, at least not on OS X, as it's not handling the
C++/C99-style dissectors in the IDL for NSPI, so we manually put the
_U_s back.
svn path=/trunk/; revision=53554
the result of pidl on dce.idl.
(We can't just regenerate it, as there are some pidl bugs that cause bad
code to be generated.)
svn path=/trunk/; revision=53541
suggest using our version of pidl, given that its Wireshark
parser generator has changes to support the current internal
Wireshark APIs for dissectors;
suggest using "--includedir ." to make IDL files in
subdirectories of epan/dissectors/pidl work;
update the list of IDL files with issues;
reformat to 80x66 (if it's good enough for Herman Hollerith,
it's good enough for me!).
svn path=/trunk/; revision=53533
again (and some various other improvements):
Rebuild the dissector with the latest xcbproto and mesa.
Subject: [PATCH 01/11] X11 dissector: Support CARD64 and INT64 types
These types are used by the new Present extension.
Subject: [PATCH 02/11] X11 dissector: Un-blacklist a few structures
The xinput structs are used by the latest xcb/proto, and the xkb
struct has been removed.
Subject: [PATCH 03/11] X11 dissector: Add hack for xinput:ChangeProperty
xinput:ChangeProperty should use switch/case, but only switch/bitcase
is supported at the moment. Add (hopefully temporary) hack.
Subject: [PATCH 04/11] X11 dissector: Use namespace for types
In particular, the name of the xsync struct 'INT64' collides with a
basic type of the same name.
Subject: [PATCH 05/11] X11 dissector: Add support for "Generic" events
All new extensions are using the new "Generic" events instead of
traditional events, because there aren't enough traditional event
numbers.
Denoted by <event xge="true"> in xcb/proto.
Subject: [PATCH 06/11] X11 dissector: Blacklist unused structures
Subject: [PATCH 07/11] X11 dissector: Support multiple enumref in a bitcase
XKB is weird.
Subject: [PATCH 08/11] X11 dissector: Support sumof
Subject: [PATCH 09/11] X11 dissector: Stop generating unused-but-set variables
(This patch also reverts r53298/r53299.)
svn path=/trunk/; revision=53532
Guy Harris