On 06/18/2012 09:30 AM, Eli Zaretskii wrote: >> At least to experiment on the concept, and on a suggestion from >> Eric Blake weeks ago, I stole bits of the coreutils, and made them >> a gnulib module. > > Perhaps the comments below, mainly related to portability to > MS-Windows (but not only that) will be helpful, even though a lot has > been said already.
Yes, porting to mingw would be helpful.
>
>> + while (*path1 && *path2)
>> + {
>> + if (*path1 != *path2)
>
> This comparison should be case-insensitive for MS-Windows.
Shouldn't normalization already guarantee canonical case, so that by the
time we get here, case-sensitive comparison is correct?
>
>> + /* Skip over extraneous '/'. */
>> + if (*relto_suffix == '/')
>> + relto_suffix++;
>> + if (*fname_suffix == '/')
>> + fname_suffix++;
>
> Why do you skip only over a single slash? Can't there be an
> arbitrarily long sequence of redundant slashes?
After canonicalization, there can be at most one location where you will
ever have consecutive '/', and that is in path names that start with //.
>
>> +/* Return FROM represented as relative to the dir of TARGET.
>> + The result is malloced. */
>
> This commentary doesn't say that the result can be NULL.
nor that NULL is _expected_ when two names have no relative relationship
(as is the case between /foo and //bar on systems where // is special,
or between a:/file and c:/file on windows).
>
>> +
>> +char *
>> +convert_abs_rel (const char *from, const char *target)
>> +{
>> + char *realtarget = canonicalize_filename_mode (target, CAN_MISSING);
>> + char *realfrom = canonicalize_filename_mode (from, CAN_MISSING);
>
> AFAICT, canonicalize_filename_mode can return NULL, but the rest of
> the code doesn't cope with that.
No, canonicalize_filename_mode is GPL because it calls xalloc() and dies
rather than return NULL.
--
Eric Blake ebl...@redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
