header type fails, as we might be capturing on more than one interface.
Report the failing interface name in single quotes in some places where
we weren't doing so, for stylistic consistency.
svn path=/trunk/; revision=53593
command line, and it works as long as all interfaces on which you're
capturing support it and that's what you really want.
There's some UI cleanup that calls for, however.
svn path=/trunk/; revision=53592
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
Guy Harris