Regarding the vhost lib...
> From: David Marchand [mailto:david.march...@redhat.com]
> Sent: Thursday, 24 August 2023 14.26
>
> On Thu, Aug 24, 2023 at 2:06 PM David Marchand
> <david.march...@redhat.com> wrote:
> > I had a look at the vhost library and I think the compiler thinks size may
> be 0.
> > Changing the loop on size with a do { } while (size > 0); resolves the
> warning.
> > I can post a change for this, as we hit a similar issue in the past
> > and the code does not make sense comparing size on the first iteration
> > of this loop.
>
> This sounds like a commit 4226aa9caca9 ("vhost: fix build with GCC
> 12") we had on LoongArch.
If we know that size > 0 initially, then "do { } while (size > 0);" is more
appropriate than "while (size > 0) { }", not only for the benefit of the
compiler/optimizer, but also for the benefit of human reviewers.
>
> And the 32bits build warning goes away with this:
>
> diff --git a/lib/vhost/virtio_net.c b/lib/vhost/virtio_net.c
> index d7624d18c8..41328b7530 100644
> --- a/lib/vhost/virtio_net.c
> +++ b/lib/vhost/virtio_net.c
> @@ -1906,7 +1906,7 @@ vhost_enqueue_async_packed(struct virtio_net *dev,
> uint16_t buf_id = 0;
> uint32_t len = 0;
> uint16_t desc_count = 0;
> - uint64_t size = pkt->pkt_len + sizeof(struct
> virtio_net_hdr_mrg_rxbuf);
> + uint64_t size = (uint64_t)pkt->pkt_len + sizeof(struct
> virtio_net_hdr_mrg_rxbuf);
Yes, but performing a 64 bit addition instead of a 32 bit addition has a (very
small) cost for 32 bit arch.
And regardless of this cost for 32 bit arch; if we know that size cannot exceed
UINT32_MAX, it should be changed to uint32_t.
> uint32_t buffer_len[vq->size];
> uint16_t buffer_buf_id[vq->size];
> uint16_t buffer_desc_count[vq->size];
