As Francois-Xavier points it out, my recent commit 5265743 in certain
contexts adds rather than removes compiler warnings:
cc: Sun C 5.12 SunOS_i386 Patch 148918-11 2017/12/13
"tcpdump.c", line 3267: warning: bad message tag: E_DEPRECATED_ATT
"tcpdump.c", line 3307: warning: bad message tag: E_DEPRECATED_ATT
Get Sun C versions right to fix that.
The diagnostic macro pair is already in place, but it is not defined for
Sun C, fix that.
OpenSSL 1.0.2za 24 Aug 2021
cc: Studio 12.6 Sun C 5.15 SunOS_i386 2017/05/30
"./print-tcp.c", line 922: warning: "MD5_Init" is deprecated,
declared in : "/usr/include/openssl/md5.h", line 124
"./print-tcp.c", line 927: warning: "MD5_Update" is deprecated,
declared in : "/usr/include/openssl/md5.h", line 125
"./print-tcp.c", line 928: warning: "MD5_Update" is deprecated...
"./print-tcp.c", line 929: warning: "MD5_Update" is deprecated...
"./print-tcp.c", line 930: warning: "MD5_Update" is deprecated...
"./print-tcp.c", line 933: warning: "MD5_Update" is deprecated...
"./print-tcp.c", line 936: warning: "MD5_Update" is deprecated...
"./print-tcp.c", line 937: warning: "MD5_Update" is deprecated...
"./print-tcp.c", line 939: warning: "MD5_Update" is deprecated...
"./print-tcp.c", line 941: warning: "MD5_Update" is deprecated...
"./print-tcp.c", line 942: warning: "MD5_Update" is deprecated...
"./print-tcp.c", line 943: warning: "MD5_Update" is deprecated...
"./print-tcp.c", line 945: warning: "MD5_Update" is deprecated...
"./print-tcp.c", line 957: warning: "MD5_Update" is deprecated...
"./print-tcp.c", line 963: warning: "MD5_Update" is deprecated...
"./print-tcp.c", line 967: warning: "MD5_Update" is deprecated...
"./print-tcp.c", line 968: warning: "MD5_Final" is deprecated,
declared in : "/usr/include/openssl/md5.h", line 126
"./signature.c", line 65: warning: "MD5_Init" is deprecated...
"./signature.c", line 66: warning: "MD5_Update" is deprecated...
"./signature.c", line 67: warning: "MD5_Final" is deprecated...
"./signature.c", line 99: warning: "MD5_Init" is deprecated...
"./signature.c", line 100: warning: "MD5_Update" is deprecated...
"./signature.c", line 101: warning: "MD5_Update" is deprecated...
"./signature.c", line 102: warning: "MD5_Final" is deprecated...
"./signature.c", line 107: warning: "MD5_Init" is deprecated...
"./signature.c", line 108: warning: "MD5_Update" is deprecated...
"./signature.c", line 109: warning: "MD5_Update" is deprecated...
"./signature.c", line 110: warning: "MD5_Final" is deprecated...
As it turns out, the root cause of Clang warnings about tcpdump.c on
illumos has to do with illumos headers rather than tcpdump. Until the
bug fix is in place and has propagated well into illumos distributions,
use a workaround: add a new pair of diagnostic control macros for Clang
only and on illumos wrap the "offending" lines with it.
In one place, we really *do* legitimately ignore the return value of
pcap_set_datalink(). We cast its return value to void, which appears to
squelch warnings from Clang, but not from at least some versions of GCC,
so provide DIAG_OFF_WARN_UNUSED_RESULT/DIAG_ON_WARN_UNUSED_RESULT and
use them to squelch the warning.
On FreeBSD CMake runs Clang with -std=gnu99, which used to emit three
warnings in a Capsicum-specific block along the following lines:
tcpdump.c:2432:32: warning: '_Generic' is a C11 extension
[-Wc11-extensions]
/usr/include/libgen.h:61:21: note: expanded from macro 'basename'
basename)(x)
/usr/include/sys/cdefs.h:325:2: note: expanded from macro '__generic'
_Generic(expr, t: yes, default: no)
(In the same context Autoconf does not request a specific C standard
from Clang, so it happens to use C17 and there is no warning.)
Type-generic expressions support in C99 mode seems to be a quirk of
Clang that cannot be disabled and is harmless in this context, so
introduce and use another pair of diagnostic control macros (for Clang
only) to squelch the warnings.
While at it, study the reason for _Generic use in /usr/include/libgen.h
and realize that tcpdump.c still assumes the behaviour before FreeBSD
12.0. Add two temporary buffers around basename() and dirname() calls
to get consistent results regardless of which FreeBSD version it is.
Remove the last remaining exemption rule.
XL C 16.1.1 Community Edition for Linux generated three warnings for
every file:
In file included from ./tcpdump.c:155:
./netdissect.h:254:8: warning: 1540-2990 The attribute
"__attribute__((format(printf, 2, 3)))" is not supported. The
attribute is ignored.
PRINTFLIKE_FUNCPTR(2, 3);
^
./netdissect.h:259:10: warning: 1540-2990 The attribute
" __attribute__((format(printf, 3, 4)))" is not supported.
The attribute is ignored.
PRINTFLIKE_FUNCPTR(3, 4);
^
./netdissect.h:263:9: warning: 1540-2990 The attribute
" __attribute__((format(printf, 2, 3)))" is not supported. The
attribute is ignored.
PRINTFLIKE_FUNCPTR(2, 3);
^
As it turns out, this is a bug in the compiler. In compiler-tests.h
update ND_IS_AT_LEAST_XL_C_VERSION() to tell newer XL C versions. In
funcattrs.h exempt XL C 16.1 from PRINTFLIKE_FUNCPTR().
In the course of preparing these changes notice that XL C uses the Clang
block in diag-control.h (XL C mimics both Clang and GCC to some extent),
although the behaviour is different between the two compilers. Add a new
block for XL C there.
In build_common.sh add more comments to explain XL C quirks and detect
XL C for Linux too so it receives the right CFLAGS. Update CHANGES to
mention this and earlier improvements.
It's explicitly cheating in some places; just cast away the warnings.
Add a Clang version testing macro to compiler-tests.h.
Move the diagnostic control #defines from netdissect-stdinc.h to
diag-control.h, libpcap-style, so that they can be used by code that
doesn't use (or need) netdissect-stdinc.h. This also means that we can
limit the inclusion of diag-control.h, and the definition of those
Do them more libpcap-style, with separate DIAG_OFF/DIAG_ON pairs for
particular issues, rather than having DIAG_OFF() and DIAG_ON() macros
that take -W option names as arguments; that way, if we need to define
them for compilers that don't have the GCC/Clang syntax for those
pragmas, e.g. MSVC, we can do so.
