[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] conf: remove redundant ()



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 redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]