[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new module: relpath
From: |
Eli Zaretskii |
Subject: |
Re: new module: relpath |
Date: |
Mon, 18 Jun 2012 19:31:09 +0300 |
> Date: Mon, 18 Jun 2012 09:39:26 -0600
> From: Eric Blake <address@hidden>
> CC: Akim Demaille <address@hidden>, address@hidden
>
> >> + 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?
Maybe, but it's not entirely clear to me it is a good idea to rely on
that. There's more than one way of canonicalizing a file name. Even
if you document that gnulib's functions should be used for that, how
those functions work may change some day. So I think it would be
better to be less dependent on what exactly a canonical file name is
on MS-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.
Maybe I'm looking at the wrong source file in gnulib. but I see these
at the beginning of canonicalize_filename_mode:
if (name == NULL)
{
errno = EINVAL;
return NULL;
}
if (name[0] == '\0')
{
errno = ENOENT;
return NULL;
}
if (name[0] != '/')
{
rname = xgetcwd ();
if (!rname)
return NULL;
- Re: new module: relpath, (continued)
Re: new module: relpath, Akim Demaille, 2012/06/17
Re: new module: relpath, Akim Demaille, 2012/06/18
Re: new module: relpath, Eli Zaretskii, 2012/06/18
- Re: new module: relpath, Eric Blake, 2012/06/18
- Re: new module: relpath,
Eli Zaretskii <=
- Re: new module: relpath, Akim Demaille, 2012/06/19
- Re: new module: relpath, Eli Zaretskii, 2012/06/19
- Re: new module: relpath, Akim Demaille, 2012/06/22
- Re: new module: relpath, Eric Blake, 2012/06/22
- Re: new module: relpath, Jim Meyering, 2012/06/22