| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Get the full log via: git log --follow netdissect-stdinc.h
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revert "Simplify AC_LBL_CHECK_COMPILER_OPT a bit."
(commit 43e88cd5b8e9d9d643bbad585743123492452041)
The problem shows itself because 'configure' displays
"checking whether the compiler supports the -Wstrict-prototypes option... no"
even if '-Wstrict-prototypes' option is supported.
Moreover:
Update configure accordingly.
Fix a trailing space.
|
| |
|
|
|
|
|
|
| |
Even if frontend/backend separation is ongoing, keep coherence between
option name and flag name at the moment.
Option name is 'm', thus s/ndo_sflag/ndo_mflag/.
|
| |
|
| |
|
|
|
|
|
| |
Moreover:
s/tcpdump/netdissect/
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Moreover:
Fix indent
|
| |
|
| |
|
|
|
|
|
| |
Libnetdissect could be used by programs not named "tcpdump". Rename
"tcpdump_printf()" to "ndo_printf()".
|
| |
|
|
|
|
|
|
|
|
| |
A program that use the library should set it. Done for tcpdump.
ndo_error() and ndo_warning() print now 'ndo->program_name'.
Moreover:
Fix indent
|
| |
|
| |
|
|
|
|
|
|
| |
Moreover:
Hamonise the output for error messages
Add istr[] in print-babel.c
|
| |
|
|
|
|
|
|
| |
An invalid packet could be:
1) built malformed originally by the sender or a fuzz tester,
2) became corrupted in transit.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
When I needed to print a string and didn't remember which of the three
functions fn_print(), fn_printn() and fn_printzp() was the right one
for the data, every time it would end up in reading through all of them
and forgetting the difference shortly after the commit.
Just having it explained in the comments should work better.
|
| |
|
|
|
|
|
|
| |
Have the line number for the file we're opening for "file" be separate
from the line number we're passed. That avoids warnings, and makes it
clearer *which* line number we're using.
|
|
|
|
|
|
| |
Rename the variable to "error_status", as that's what it represents, and
as that doesn't collide with the error() function. Don't set it and
then not use the resulting value.
|
|
|
|
| |
Those variables are counts, so just give them names that reflects that.
|
|
|
|
|
| |
Just call the variable "data", not "print_data"; we're obviously
printing it.
|
|
|
|
| |
strlen() is a standard C function, so don't use its name for a variable.
|
|
|
|
|
|
|
| |
Rename the variable "index" to "idx", so that if the environment in
which we're compiling tcpdump happens to declare the index() function
(the old V7 name for the function called strchr() in S3/S5 and ANSI C),
we don't get compiler warnings.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's _WIN32, with a leading underscore, not WIN32. See, for example:
https://sourceforge.net/p/predef/wiki/OperatingSystems/
and
https://msdn.microsoft.com/en-us/library/b0084kay.aspx
*Some* environments may also define WIN32, but we shouldn't depend on
that.
|
|
|
|
| |
"dB".
|
|\
| |
| | |
dBm values get printed as dB
|
|/
|
| |
This is a very old bug, and I think it's time to get fixed :-)
|
|
|
|
|
| |
From GitHub issue #478, in which tcpdump crashed on SPARC due to making
an unaligned access.
|
|
|
|
|
|
|
| |
Use UNALIGNED_MEMCPY() to extract the XID from it; otherwise, this might
crash on machines that require strict alignment (e.g., SPARC machines).
Fixes GitHub issue #478.
|
| |
|
|
|
|
|
| |
The warnings were:
comma at end of enumerator list [-Wpedantic]
|
|
|
|
|
|
|
|
| |
The warning was:
./tcpdump.c: In function 'droproot':
./tcpdump.c:496:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
int ret = capng_change_id(pw->pw_uid, pw->pw_gid, CAPNG_NO_FLAG);
^
|
| |
|
|
|
|
|
| |
The complete warnings were:
ISO C90 does not support the '%T' gnu_strftime format [-Wformat=]
|
|
|
|
|
| |
The complete warnings were:
ISO C90 does not support the '%lf' gnu_printf format [-Wformat=]
|
|
|
|
|
| |
677:31: warning: variable ‘router_id’ set but not used
676:72: warning: variable ‘hopc’ set but not used
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't speak of "Ethernet" and "wire", as you might not be sniffing an
Ethernet or, indeed, any form of wired network.
Note that not only could there be a delay between the point at which the
interface is finished receiving the packet and when an interrupt is
delivered (whether due to bus delays, polling rather than immediate
interrupts being used, or delays in the CPU responding to the interrupt,
or more than one of those) but also a delay between the point at which
the kernel responds to the interrupt and the point at which it actually
applies a time stamp to the packet.
|