On 04/19/2012 06:10 PM, Laine Stump wrote:
On 04/19/2012 04:21 PM, Eric Blake wrote:
> I almost copied-and-pasted some redundant () into my new code,
> and figured a general cleanup prereq patch would be better instead.
>
> * src/conf/domain_conf.c (virDomainLeaseDefParseXML)
> (virDomainDiskDefParseXML, virDomainFSDefParseXML)
> (virDomainActualNetDefParseXML, virDomainNetDefParseXML)
> (virDomainGraphicsDefParseXML, virDomainVideoAccelDefParseXML)
> (virDomainVideoDefParseXML, virDomainHostdevFind)
> (virDomainControllerInsertPreAlloced, virDomainDefParseXML)
> (virDomainObjParseXML, virDomainCpuSetFormat)
> (virDomainCpuSetParse, virDomainDiskDefFormat)
> (virDomainActualNetDefFormat, virDomainNetDefFormat)
> (virDomainTimerDefFormat, virDomainGraphicsListenDefFormat)
> (virDomainDefFormatInternal, virDomainNetGetActualHostdev)
> (virDomainNetGetActualBandwidth, virDomainGraphicsGetListen):
> Reduce extra (), per coding styles.
Actually the libvirt coding style given in HACKING doesn't say anything
about superfluous parentheses (not that I can find). Maybe you're
thinking of coreutils, or gnulib?
Hmm, then I'll shorten that out of the commit message.
I have one reservation, though - this is a lot of code churn, which
increases the likelyhood of merge conflicts when backporting anything
from future code to any recently rebased distro packages (unless you
plan to backport this patch prior to any other backports). I guess it
all comes down to whether you think the advantages of cleaner looking
code outweighs potential time spent resolving extra conflicts (of
course, if you think it's unlikely any bugfixes will need to be
backported to any of this code, then that's a non-problem).
Yeah, but I ran into this due to a review comment on my block migration
patches. Either it will conflict right away (and then this is
effectively part of that series for doing a backport), or it won't
conflict for me and therefore likely won't conflict for other backport
patches, so I'm willing to accept the risk to backporting.
I've gone ahead and pushed this.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org