Usually, of course, it's invalid to pass a NULL buffer to recv(). However, it's acceptable when using MSG_TRUNC, because that suppresses actually writing to the buffer. So, we pass NULL in tcp_sock_consume(). Unfortunately, checker tools aren't always aware of that special case: we already have a suppression for cppcheck to cover this. valgrind-3.22.0 (present in Fedora 39) has a similar problem, generating a spurious warning here. We could generate another suppression for valgrind, however, it so happens that we already have tcp_buf_discard ready to hand. If we pass this instead of NULL it makes both cppcheck and valgrind happy. We're still using the MSG_TRUNC flag, the kernel doesn't actually have to copy data, so we should still have the performance benefits of it. Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- tcp.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/tcp.c b/tcp.c index cfcd40a..f51d27a 100644 --- a/tcp.c +++ b/tcp.c @@ -2106,8 +2106,13 @@ static int tcp_sock_consume(const struct tcp_tap_conn *conn, uint32_t ack_seq) if (SEQ_LE(ack_seq, conn->seq_ack_from_tap)) return 0; - /* cppcheck-suppress [nullPointer, unmatchedSuppression] */ - if (recv(conn->sock, NULL, ack_seq - conn->seq_ack_from_tap, + /* Since we're using MSG_TRUNC, it's allowed to pass NULL instead of a + * real buffer. However some checker tools (including at least some + * versions of cppcheck and valgrind) aren't aware of that special case. + * We so happen to have a convenient discard buffer, so we might as well + * pass it to avoid spurious complaints from those tools. + */ + if (recv(conn->sock, tcp_buf_discard, ack_seq - conn->seq_ack_from_tap, MSG_DONTWAIT | MSG_TRUNC) < 0) return -errno; -- 2.41.0