Re: [PATCH 2/3] util: Introduce virFileComparePaths

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

 



> > + * Returns 0 if the paths are equal, 1 if they're not or -1 in case of an
> > + * error.
> > + */
> > +int
> > +virFileComparePaths(const char *p1, const char *p2)
> 
> I think this be "virFileCompareResolvedPaths" - change all the places...
>  Better representation than just ComparePaths
> 

Well, having the substring "Resolved" in the name IMHO implies that the paths
to be compared should already by resolved in which case the whole point of the
function doesn't make sense, since you'd simply use STREQ. So for this reason I
prefer just ComparePaths. I really wanted it to be called *Equal but sort of
implies the return type boolean which is inapplicable because of the VIR_STRDUP
:(.

> > +{
> > +    int ret = -1;
> > +    char *res1, *res2;
> > +
> > +    res1 = res2 = NULL;
> > +
> > +    /* Assume p1 and p2 are symlinks, so try to resolve and canonicalize them.
> > +     * Canonicalization fails for example on file systems names like 'proc' or
> > +     * 'sysfs', since they're no real paths so fallback to plain string
> > +     * comparison.
> > +     */
> > +    ignore_value(virFileResolveLink(p1, &res1));
> > +    if (!res1 && VIR_STRDUP(res1, p1) < 0)
> > +        goto cleanup;
> > +
> > +    ignore_value(virFileResolveLink(p2, &res2));
> > +    if (!res2 && VIR_STRDUP(res2, p2) < 0)
> > +        goto cleanup;
> > +
> > +    if (STREQ_NULLABLE(res1, res2))
> > +        ret = 0;
> > +    else
> > +        ret = 1;
> 
> WHy not return 1 on match, 0 on non match, and -1 on failure that way
> all you have to do is "ret = STREQ_NULLABLE(res1, res2);"... If so
> adjust the returns comments above too.
>

Well, that was my initial thought, the code would look cleaner, I also liked it
more, but then I thought, most of our compare functions use strcmp for
comparison at some point, so I wanted to follow the convention of returning 0
when equal. However, it wasn't until you suggested it that I grep'ed our code 
and found virReadCompareWWN that works exactly the way I'd favour. So, yeah, I
should have gone with my initial gut feeling, I'll adjust this appropriately,
thanks.

Erik

> 
> ACK w/ adjustments.
> 
> > +
> > + cleanup:
> > +    VIR_FREE(res1);
> > +    VIR_FREE(res2);
> > +    return ret;
> > +}
> > diff --git a/src/util/virfile.h b/src/util/virfile.h
> > index 0343acd..5822b29 100644
> > --- a/src/util/virfile.h
> > +++ b/src/util/virfile.h
> > @@ -331,4 +331,6 @@ void virFileFreeACLs(void **acl);
> >  
> >  int virFileCopyACLs(const char *src,
> >                      const char *dst);
> > +
> > +int virFileComparePaths(const char *p1, const char *p2);
> >  #endif /* __VIR_FILE_H */
> > 
> 
> --
> libvir-list mailing list
> libvir-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/libvir-list

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux