https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107750
--- Comment #6 from Rainer Orth <ro at gcc dot gnu.org> ---
David, after your amazing work on PR analyzer/111475, there are only a handful
of analyzer failures left on trunk:
FAIL: gcc.dg/analyzer/fd-accept.c (test for excess errors)
FAIL: gcc.dg/analyzer/fd-accept.c final event at line 58 (test for warnings,
line 57)
FAIL: gcc.dg/analyzer/fd-accept.c warning (test for warnings, line 57)
FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line
19)
FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line
27)
FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line
32)
FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line
39)
FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line
55)
FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for excess errors)
FAIL: gcc.dg/analyzer/fd-connect.c (test for warnings, line 35)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 13)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 32)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 38)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 50)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 72)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 83)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 86)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 94)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for warnings, line 98)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for excess errors)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c final event at line 110 (test for
warnings, line 109)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c final event at line 88 (test for
warnings, line 87)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c warning (test for warnings, line
109)
FAIL: gcc.dg/analyzer/fd-datagram-socket.c warning (test for warnings, line 87)
FAIL: gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c (test for excess
errors)
FAIL: gcc.dg/analyzer/fd-listen.c (test for excess errors)
FAIL: gcc.dg/analyzer/fd-listen.c final event at line 55 (test for warnings,
line 54)
FAIL: gcc.dg/analyzer/fd-listen.c warning (test for warnings, line 54)
FAIL: gcc.dg/analyzer/fd-socket-misuse.c (test for warnings, line 18)
FAIL: gcc.dg/analyzer/fd-socket-misuse.c (test for excess errors)
FAIL: gcc.dg/analyzer/fd-socket-misuse.c final event at line 22 (test for
warnings, line 21)
FAIL: gcc.dg/analyzer/fd-socket-misuse.c warning (test for warnings, line 21)
FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line
21)
FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line
32)
FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line
39)
FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for warnings, line
47)
FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for excess errors)
FAIL: gcc.dg/analyzer/fd-stream-socket-passive-open.c (test for warnings, line
27)
FAIL: gcc.dg/analyzer/fd-stream-socket-passive-open.c (test for warnings, line
35)
FAIL: gcc.dg/analyzer/fd-stream-socket-passive-open.c (test for warnings, line
41)
FAIL: gcc.dg/analyzer/fd-stream-socket-passive-open.c (test for warnings, line
46)
FAIL: gcc.dg/analyzer/fd-stream-socket-passive-open.c (test for excess errors)
FAIL: gcc.dg/analyzer/fd-stream-socket.c (test for warnings, line 13)
FAIL: gcc.dg/analyzer/fd-stream-socket.c (test for warnings, line 37)
FAIL: gcc.dg/analyzer/fd-stream-socket.c (test for warnings, line 70)
FAIL: gcc.dg/analyzer/fd-stream-socket.c (test for warnings, line 81)
FAIL: gcc.dg/analyzer/fd-stream-socket.c (test for warnings, line 92)
As an example, I looked into fd-accept.c, which shows those differences between
Linux and Solaris output:
--- /homes/ro/fd-accept.out.i.linux 2024-05-08 13:19:07.595246605 +0200
+++ fd-accept.out.i 2024-05-08 13:23:30.986283368 +0200
@@ -23,2 +23,2 @@
-/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-accept.c:57:3:
warning: ‘accept’ on datagram socket file descriptor ‘fd’
[-Wanalyzer-fd-type-mismatch]
-/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-accept.c:54:12:
note: (1) datagram socket created here
+/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-accept.c:57:3:
warning: ‘accept’ on file descriptor ‘fd’ in wrong phase [CWE-666]
[-Wanalyzer-fd-phase-mismatch]
+/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-accept.c:54:12:
note: (1) socket created here
@@ -28 +28 @@
-/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-accept.c:57:3:
note: (5) ‘accept’ expects a stream socket file descriptor but ‘fd’ is a
datagram socket
+/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/fd-accept.c:57:3:
note: (5) ‘accept’ expects a listening stream socket file descriptor but ‘fd’
has not yet been bound
Obviously the analyzer couldn't determine that fd is a datagram socket in
test_accept_on_new_datagram_socket.
However, if I compile the preprocessed Linux fd-accept.i on Solaris, I get
the same output as on Linux.
While Linux <x86_64-linux-gnu/bits/socket_type.h> has
enum __socket_type
{
SOCK_STREAM = 1, /* Sequenced, reliable, connection-based
byte streams. */
#define SOCK_STREAM SOCK_STREAM
SOCK_DGRAM = 2, /* Connectionless, unreliable datagrams
of fixed maximum length. */
#define SOCK_DGRAM SOCK_DGRAM
Solaris <sys/socket.h> has plain #define's instead:
#define SOCK_STREAM 2 /* stream socket */
#define SOCK_DGRAM 1 /* datagram socket */
As yo suspected in Comment #2, the analyzer seems unable to handle that yet.
As an experiment, I hacked the SOCK_STREAM and SOCK_DGRAM definitions in
fd-accept.i on Solaris
to also use an enum instead, the test now produces the same output as on Linux.
I also had a quick look into AIX 7.2 <sys/socket.h> and found it also uses
#define's for the SOCK_* constants, thus explaining that the tests FAIL there,
too.
FreeBSD 14.0 <sys/socket.h> is the same, so this seems to be a common theme.
