From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Brivio To: passt-dev@passt.top Subject: Re: [PATCH 21/28] cppcheck: Suppress NULL pointer warning in tcp_sock_consume() Date: Wed, 28 Sep 2022 22:58:37 +0200 Message-ID: <20220928225837.190a0fed@elisabeth> In-Reply-To: <20220928043339.613538-22-david@gibson.dropbear.id.au> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5969243743939991072==" --===============5969243743939991072== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 28 Sep 2022 14:33:32 +1000 David Gibson wrote: > Recent versions of cppcheck give a warning due to the NULL buffer passed > to recv() in tcp_sock_consume(). Since this apparently works, I assume > it's actually valid, Yes, given that we use MSG_TRUNC to discard socket buffers, I thought it's cleaner to avoid supplying a data buffer altogether. POSIX doesn't specify MSG_TRUNC, and whether the buffer can be NULL isn't specified in Linux documentation, but it works reliably (the kernel won't even look at it). This was actually the first step of a long-overdue plan: if you observe this through perf(1), you'll see some overhead in the kernel, which looks a bit more than a reasonable expectation for pure syscall overhead. So, I planned to check if we can simplify the kernel path if no buffer is passed. I'll track this somewhere next week. Even the day we add a vhost-user back-end, this overhead is still going to be there, as that wouldn't change anything host-side. > but cppcheck doesn't know that recv() can take a NULL > buffer. So, use a suppression to get rid of the error. valgrind didn't know either, by the way -- see the corresponding suppression in test/valgrind.supp. -- Stefano --===============5969243743939991072==--