| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Since diagnostic macros do not depend on each other, use the same
approach as in tcpslice: make one or more attempts to define a
diagnostic macro depending on conditions of varying complexity; if after
all the busy branching the macro is not yet defined, define it to an
empty string once. This way the branches are simpler to rearrange when
required, and the file has a manifest of the macro names it defines.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Test for whether we're using Clang 2.8 or later or GCC 4.6 or later,
rather than testing for MSVC; that way, we define it for Microsoft's
clang-cl (which is Clang-based, so we want it defined, but it defines
_MSC_VER) and don't define it for compilers that aren't MSVC, Clang, or
GCC.
This should fix issue #1115.
|
| |
|
|
|
|
|
|
| |
As Gisle Vanem notes, "...using clang-cl on Windows to compile with (a
MSVC-compatible compiler driver), this includes _MSC_VER as
a built-in. Hence the above blocks should be swapped..."
This fixes issue #1101.
|
| |
|
|
|
|
|
|
| |
Windows programs shouldn't use pcap_fileno(); we're already deprecating
it, and the fix for GitHub issue #1026 squelches the warning in a
fashion that doesn't require any DIAG_OFF/DIAG_ON stuff, and there's no
reason for us to care how a deprecated function works around its
brokenness-by-design.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Use that for pcap_fileno() on Windows; that API shouldn't exist on
Windows, and should never be used, but WinPcap offered it, so we're
stuck with it. At least try to prevent compilation errors when libpcap
is built.
This should fix the warnings for pcap_fileno() in GitHub issue #1026.
|
| |
|
|
| |
Refine the changes made in commit 3f35396 and use a macro with comments.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently, GCC 4.6.4 didn't like it:
pcap-new.c:241:4: warning: unknown option after '#pragma GCC diagnostic'
kind [-Wpragmas]
pcap-new.c:259:4: warning: unknown option after '#pragma GCC diagnostic'
kind [-Wpragmas]
pcap-new.c:452:2: warning: unknown option after '#pragma GCC diagnostic'
kind [-Wpragmas]
pcap-rpcap.c:3369:4: warning: unknown option after '#pragma GCC
diagnostic' kind [-Wpragmas]
pcap-rpcap.c:3406:4: warning: unknown option after '#pragma GCC
diagnostic' kind [-Wpragmas]
rpcapd.c:1365:4: warning: unknown option after '#pragma GCC diagnostic'
kind [-Wpragmas]
|
| |
|
|
|
|
| |
These were format-truncation warnings (See issue #1029).
This is a workaround while waiting for a fix.
|
| | |
|
| |
|
|
| |
That's generated code over which we have no control.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The AppVeyor CI builder started warning about switch statements in which
not all enum values were handled explicitly on the VS 1019 build. We
can't test for the enum values at compile time, the way we could test
for #defines, so, for now, we punt on the NdisPhysicalMedium enums and
just suppress that diagnostic for that switch statement.
We add MediaConnectStateUnknown to the switch for the connect state;
that one is presumably there if the enum is there at all.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I don't know whether a Windows HANDLE can be expected to survive
conversion to an int - and there's no need for it to have to be
converted. If a caller needs to do something with a HANDLE associated
with a pcap_t, it should call the new pcap_handle() routine and get a
HANDLE; code for UN*X that uses the result of pcap_fileno() is unlikely
to work on Windows anyway.
Squelch the "pointer truncation from 'HANDLE' to 'DWORD'" warning, as,
if that truncation causes an issue, callers should use pcap_handle(),
and if it *doesn't* cause an issue, it's, well, not an issue.
|
| |
|
|
|
|
| |
Yes, we know, we shouldn't use it. We only use it to provide a routine
that we've exported for a long time (and thus can't necessarily remove),
and which *we* now deprecate.
|
| |
|
|
|
|
|
|
|
|
| |
MSVC may warn about a push not matched by a pop if we don't use
DIAG_ON_BISON_BYACC, and there's no way to ensure that
DIAG_ON_BISON_BYACC is placed after *all* Berkeley YACC-generated
code, so we can't make it work.
Instead, don't do a push in DIAG_OFF_BISON_BYACC, and don't define or
use DIAG_ON_BISON_BYACC.
|
| | |
|
| |
|
|
|
| |
We're supposedly suppressing that warning with Flex; more debugging is
necessary.
|
| |
|
|
|
|
|
|
| |
We're seeing them with OpenBSD 6.3 and Bison 3.0.4.
While we're at ti, update some comments to reflect that, with Berkeley
YACC, we supportess unreachable code warnings with MSVC, GCC, and Clang,
not just with MSVC.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Signed-off-by: Joerg Mayer <jmayer@loplof.de>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Also suppress the one non-fixable warning:
build/scanner.c:5020:1: warning: function 'yy_fatal_error' could be
declared with attribute 'noreturn' [-Wmissing-noreturn]
Signed-off-by: Joerg Mayer <jmayer@loplof.de>
|
| |
|
|
|
|
|
|
| |
Flex 2.5.35 Apple(flex-31) appears to generate comments that Clang's
-Wdocumentation doesn't like.
Comment-updated-by: Guy Harris <guy@alum.mit.edu>
Signed-off-by: Joerg Mayer <jmayer@loplof.de>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
With at least some versions of GCC, we need to suppress the -Wshadow
diagnostics before the global variable is defined as well as before the
local variable is defined, otherwise only the complaint about grammar.c
is suppressed, not the compaint about grammar.h.
|
