[libvirt] [PATCH 0/2] Yet another round of build fixes

Peter Krempa pkrempa at redhat.com
Mon May 30 14:56:12 UTC 2016

On Mon, May 30, 2016 at 15:53:08 +0200, Michal Privoznik wrote:
> After these regular errors, I still cannot build cleanly:
> ../../src/conf/domain_conf.c: In function 'virDomainChrPreAlloc':
> ../../src/conf/domain_conf.c:14109:57: error: potential null pointer dereference [-Werror=null-dereference]
>      return VIR_REALLOC_N(*arrPtr, *cntPtr + 1);
>                                                          ^
> ../../src/conf/domain_conf.c: In function 'virDomainChrRemove':
> ../../src/conf/domain_conf.c:14133:21: error: potential null pointer dereference [-Werror=null-dereference]
>      for (i = 0; i < *cntPtr; i++) {
>                      ^~~~~~~
> cc1: all warnings being treated as errors
> These are obviously false positives. I know some developers here
> are not very fond of fixing those, so my question is - is it
> worth the effort or will my patches be NACKed straight away?

Looking at the code I'm not surprised that the compiler thinks that it's
a null-deref. The only reason why it isn't is that we don't ever pass
the VIR_DOMAIN_CHR_DEVICE_TYPE_LAST as device type and that's very hard
to infer.

An option would be to remove the monstrosity called
virDomainChrGetDomainPtrsInternal and friends and mabye produce a saner
code that will be easier to introspect both for humans and compilers.

> Michal Privoznik (2):
>   apibuild: Substitute only pure number tokens
>   virSocketAddrIsPrivate: Work on 32bits platforms

ACK to those two. This time I verified that I've applied the patch prior
to trying to break it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160530/685cb8f5/attachment-0001.sig>

More information about the libvir-list mailing list