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".