On Wed, Apr 07, 2010 at 11:29:07AM +0200, Jiri Denemark wrote: > > > guest->arch.defaultInfo.emulator_mtime = binary_mtime; > > > > > > - if (qemudProbeCPUModels(binary, info->arch, &ncpus, NULL) == 0 > > > + if (caps->host.cpu > > > + && qemudProbeCPUModels(binary, info->arch, &ncpus, NULL) == 0 > > > && ncpus > 0 > > > && !virCapabilitiesAddGuestFeature(guest, "cpuselection", 1, 0)) > > > goto error; > > > > We usually put && on end of line, > Yeah, usually, although not always :-) I prefer it this way as you don't have > to look at the end of line to check if that line is part of the condition or > not. But I don't really care too much and I can change it. > > > and I really prefer fully parenthesized tests expressions > Hmm, I don't :-) Because you can see the difference if you mistakenly type = > instead of == there (well, not in this exact case, but in general): > > if (x = 0) vs. if ((x = 0)) > > In the first case gcc would warn you but in the second one it wouldn't. So I > prefer extra parentheses to be put only around assignments not tests to reveal > this kind of typos. If you're afraid of == turning into = then do what peopel suggest which is to swap the arguments (foo() = bar) or (0 = bar) will both be caught and even more drastically by compilers, but the expression will be readable/understandable without trying to remember what is the order of priorities for operators in C ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list