Re: [libvirt] [PATCH] Make really sure we don't access non-existing vCPUs

On Tue, Jul 12, 2016 at 03:01:57PM +0200, Peter Krempa wrote: Well, if nobody uses that, feel free to send a patch removing all mingw functionality then. It is, but only thanks to how we work with the structure. Since def->vcpus is not virDomainVcpuDefPtr but rather _array_ of virDomainVcpuDefPtr, then it *can* be NULL very easily. I know we don't deal with checking member[x] when x < nmembers, but OTOH it's not that often array of pointers. Also we do this very similar thing somewhere else, and the compiler doesn't complain, so we can change to that or just leave it as it is. Just so you know, my reasoning for this was that sparse vcpus could cause the array to be not mapped fully. I see now that every one of those pointers are mapped even when it's not needed, so I guess that's invalid. No idea why we have that as an array of pointers then. The toolchain is actually not broken. The assumption from the syntactic POV is valid. If we thought it is broken we'd probably use -Wno-null-dereference or similar. If two lines of dead code (that are clearly readable) are that annoying to you (more than size_t->int->size_t hindering readability in that function), I suggest raising that concern in a separate discussion on the ML so that we have a consensus about dealing with MinGW, clang, coverity, gcc > 4.9 and other scenarios that cause this. Way less people will read it when it's just part of a review for three-line build-breaker (from my experience). I, for one, don't really care about this that much, so I won't push this. Let's see how we resolve this once and for all (unless someone pushes another patch under the build-breaker rule).