On Tue, Feb 09, 2016 at 09:08:49 +0100, Michal Privoznik wrote: > Older gcc fails to see that the variable is set iff @hasPriority > == true in which case the former is set a value. Initialize the > value while declaring it to make the compiler shut up. > Initializing it may confuse a next reader, since there is no default value that would make sense at this point. > Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com&gt; > --- > > This maybe isn't the best approach, to workaround false > positives. I'm open to discussion. I'd suggest using non-broken compilers on non-ancient platforms and leaving the code be.

On Tue, Feb 09, 2016 at 09:29:48 +0100, Michal Privoznik wrote: > On 09.02.2016 09:26, Peter Krempa wrote: >> On Tue, Feb 09, 2016 at 09:08:49 +0100, Michal Privoznik wrote: >>> --- >>> >>> This maybe isn't the best approach, to workaround false >>> positives. I'm open to discussion. >> >> I'd suggest using non-broken compilers on non-ancient platforms and >> leaving the code be. > > Sometimes it's not possible. One can hardly expect a gcc upgrade on say > RHEL-6 or CentOS-6. Question is, why would somebody want to compile > libvirt from git on such stable systems, right? On the other hand, we > tend to be build error free previously even on such systems. You have to draw a line at some point. Your generic upstream libvirt won't just work with qemu on CentOS-6 since it was so heavily patched that the downstream libvirt carries a rather huge amount of patches that make them work together. This implies that it would require a upstream rebuild of qemu too. At that point you certainly don't get any of the "enterprise" reasons to use an enterprise as stability and testing and other stuff, so you might as well as upgrade anyways. Maybe it's time to finally stop fixing it to see whether people complain.