Message ID | 20200930155859.303148-3-borntraeger@de.ibm.com |
---|---|
State | New |
Headers | show |
Series | assorted gcc 10/fedora32 compile warning fixes | expand |
On 9/30/20 10:58 AM, Christian Borntraeger wrote: > gcc 10 from Fedora 32 gives me: > > Compiling C object libblock.fa.p/nbd_server.c.o > ../nbd/server.c: In function ‘nbd_co_client_start’: > ../nbd/server.c:625:14: error: ‘namelen’ may be used uninitialized in this function [-Werror=maybe-uninitialized] > 625 | rc = nbd_negotiate_send_info(client, NBD_INFO_NAME, namelen, name, > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 626 | errp); > | ~~~~~ > ../nbd/server.c:564:14: note: ‘namelen’ was declared here > 564 | uint32_t namelen; > | ^~~~~~~ > cc1: all warnings being treated as errors > > As I cannot see how this can happen, let uns silence the warning. gcc is smart enough to see that nbd_opt_read_name(... &namelen), which is the only use of namelen between declaration and use, does not always initialize namelen; but fails to see we also exit this function early in the same conditions when nbd_opt_read_name left namelen uninit. The workaround is fine. Reviewed-by: Eric Blake <eblake@redhat.com> I'm happy for this to go in through the trivial tree, but I'll also queue it on my NBD tree if that is ready first. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
On 30.09.20 19:19, Eric Blake wrote: > On 9/30/20 10:58 AM, Christian Borntraeger wrote: >> gcc 10 from Fedora 32 gives me: >> >> Compiling C object libblock.fa.p/nbd_server.c.o >> ../nbd/server.c: In function ‘nbd_co_client_start’: >> ../nbd/server.c:625:14: error: ‘namelen’ may be used uninitialized in this function [-Werror=maybe-uninitialized] >> 625 | rc = nbd_negotiate_send_info(client, NBD_INFO_NAME, namelen, name, >> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 626 | errp); >> | ~~~~~ >> ../nbd/server.c:564:14: note: ‘namelen’ was declared here >> 564 | uint32_t namelen; >> | ^~~~~~~ >> cc1: all warnings being treated as errors >> >> As I cannot see how this can happen, let uns silence the warning. > > gcc is smart enough to see that nbd_opt_read_name(... &namelen), which > is the only use of namelen between declaration and use, does not always > initialize namelen; but fails to see we also exit this function early in > the same conditions when nbd_opt_read_name left namelen uninit. The > workaround is fine. > > Reviewed-by: Eric Blake <eblake@redhat.com> > > I'm happy for this to go in through the trivial tree, but I'll also > queue it on my NBD tree if that is ready first. Just in case cc qemu-trival.
diff --git a/nbd/server.c b/nbd/server.c index 982de67816a7..2ff04ee7533d 100644 --- a/nbd/server.c +++ b/nbd/server.c @@ -561,7 +561,7 @@ static int nbd_negotiate_handle_info(NBDClient *client, Error **errp) NBDExport *exp; uint16_t requests; uint16_t request; - uint32_t namelen; + uint32_t namelen = 0; bool sendname = false; bool blocksize = false; uint32_t sizes[3];
gcc 10 from Fedora 32 gives me: Compiling C object libblock.fa.p/nbd_server.c.o ../nbd/server.c: In function ‘nbd_co_client_start’: ../nbd/server.c:625:14: error: ‘namelen’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 625 | rc = nbd_negotiate_send_info(client, NBD_INFO_NAME, namelen, name, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 626 | errp); | ~~~~~ ../nbd/server.c:564:14: note: ‘namelen’ was declared here 564 | uint32_t namelen; | ^~~~~~~ cc1: all warnings being treated as errors As I cannot see how this can happen, let uns silence the warning. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> --- nbd/server.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)