On Mon, Feb 18, 2019 at 08:28:54AM -0500, John Ferlan wrote: > > > On 2/18/19 7:51 AM, Peter Krempa wrote: > > On Mon, Feb 18, 2019 at 07:38:34 -0500, John Ferlan wrote: > >> > >> > >> On 2/18/19 7:27 AM, Peter Krempa wrote: > >>> Commit dcda2bf4c110 forgot to fix this one instance. > >>> > >>> Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx> > >>> --- > >>> src/util/virstoragefile.c | 14 ++++++-------- > >>> 1 file changed, 6 insertions(+), 8 deletions(-) > >>> > >> > >> Right fix as far as I'm concerned; however, I am curious to know whether > >> this passes the MinGW build test because this is exactly where things > >> started to break down for VIR_AUTOPTR usage. > > > > We'll see after I push it. I don't have mingw deployed and don't care > > enough about that platform to do so. > > > > Cannot disagree about the relevance of the importance of MinGW. Still I > note it because it was something that caused previous changes to add > VIR_AUTOPTR for this module to not be pushed. I was pointed in the > direction of Andrea and the lcitool, but TBH that didn't help me much. > Eventually I noted that Erik had run a build via some link between > travis-ci.org and a github repo. I was able to do something similar and > found a similar failure. This actually passes the build on MinGW: https://travis-ci.org/eskultety/libvirt > > >> > >> VIR_AUTOUNREF could also be used more liberally in this module... > > > > I'll not pursue this refactor. > > > >> > >>> diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c > >>> index 5927140a66..b2e308d81d 100644 > >>> --- a/src/util/virstoragefile.c > >>> +++ b/src/util/virstoragefile.c > >>> @@ -1119,22 +1119,20 @@ static virStorageSourcePtr > >>> virStorageFileMetadataNew(const char *path, > >>> int format) > >>> { > >>> - virStorageSourcePtr def = NULL; > >>> + VIR_AUTOUNREF(virStorageSourcePtr) def = NULL; > >>> + virStorageSourcePtr ret = NULL; > >> > >> Erik prefers the usage of VIR_AUTO* defs last (IOW, swap these). > > > > Well I prefer if the returned variable is last and if the longer lines > > are first. > > > > Picking and choosing which review comments to follow is an interesting > decision - hopefully it's not contagious. > > Consistency wise, VIR_AUTO* defs have been last. If it's that important > I suppose per usual someone can come in afterwards and propose another > patch as well as either a rule in/for make check or adjustment to the > hacking guide. I am obviously in favour of consistency and I'd like to us to follow it, but of' course as a reviewer you can't really force the author to do that :/.. well, wechnically we could abuse perl once again for "the rescue" and create a syntax-check rule, but HELL no...I agree that we might want to mention this in the HACKING guide. Erik
