Some people have expressed an interest in setting up
a libvirt autobuilder using clang. If you do that, be aware that
you'll see an ugly looking NULL-deref problem when using the clang
that comes with F12 or F13, but if you're using a new enough version
(rawhide), it's gone. The offending code is in qemu_monitor.c around
line 377 and involves the CMSG_* macros:
365 memset(&msg, 0, sizeof(msg));
366
367 iov[0].iov_base = (void *)data;
368 iov[0].iov_len = len;
369
370 msg.msg_iov = iov;
371 msg.msg_iovlen = 1;
372
373 msg.msg_control = control;
374 msg.msg_controllen = sizeof(control);
375
376 cmsg = CMSG_FIRSTHDR(&msg)((size_t) (&msg)->msg_controllen >= sizeof (struct cmsghdr
) ? (struct cmsghdr *) (&msg)->msg_control : (struct cmsghdr *) 0);
*** 2 Null pointer value stored to 'cmsg'
377 cmsg->cmsg_len = CMSG_LEN(sizeof(int))((((sizeof (struct cmsghdr)) + sizeof (size_t) - 1) & (size_t) ~(sizeof (size_t) - 1)) + (sizeof(int)));
*** 3 Dereference of null pointer
Presuming this code is actually exercised, it's obviously
not dereferencing NULL, so it would be a false positive.
I looked at a few usage examples and it seems like glibc's
own tests do allocate more storage. If this code is *not*
currently being used, we should model it after the glibc test code.
-----------------------------------------
FYI, anyone can (and all developers should) run clang.
It's simple, but does require a configure-from-scratch,
so it's good to keep a separate
Build like this:
scan-build -o clang ./autogen.sh --enable-compile-warnings=maximum &&
scan-build -o clang make
The "-o clang" tells it to put results in a new directory named "clang".
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list