Otherwise, with new enough gcc compiling at -O2, the build fails with: ../../src/conf/domain_conf.c: In function ‘virDomainDeviceDefPostParse’: ../../src/conf/domain_conf.c:2821:29: error: ‘cnt’ may be used uninitialized in this function [-Werror=maybe-uninitialized] for (i = 0; i < *cnt; i++) { ^ ../../src/conf/domain_conf.c:2795:20: note: ‘cnt’ was declared here size_t i, *cnt; ^ ../../src/conf/domain_conf.c:2794:30: error: ‘arrPtr’ may be used uninitialized in this function [-Werror=maybe-uninitialized] virDomainChrDefPtr **arrPtr; ^ * src/conf/domain_conf.c (virDomainChrGetDomainPtrs): Always assign into output parameters. Signed-off-by: Eric Blake <eblake(a)redhat.com&gt; --- Pushing under the build-breaker rule. I actually found this while running ./autobuild.sh; but there, we run libtool in both static and shared modes, and libtool, in its "infinite wisdom", assumes that if the static build succeeds, then the shared build can have compiler output redirected to /dev/null, which meant I was stuck debugging this output: CC libvirt_driver_test_la-test_driver.lo CC libvirt_driver_remote_la-remote_driver.lo CC libvirt_driver_remote_la-remote_protocol.lo make[3]: *** [libvirt_conf_la-domain_conf.lo] Error 1 make[3]: *** Waiting for unfinished jobs.... thanks for nothing, libtool. src/conf/domain_conf.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 0e74039..a86be8c 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -10221,6 +10221,8 @@ virDomainChrGetDomainPtrs(virDomainDefPtr vmdef, break; case VIR_DOMAIN_CHR_DEVICE_TYPE_LAST: + *arrPtr = NULL; + *cntPtr = NULL; break; } } -- 1.8.3.1