[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new module: relpath
From: |
Akim Demaille |
Subject: |
Re: new module: relpath |
Date: |
Fri, 22 Jun 2012 14:02:57 +0200 |
Hi Eli,
Le 19 juin 2012 à 17:51, Eli Zaretskii a écrit :
>> From: Akim Demaille <address@hidden>
>> Date: Tue, 19 Jun 2012 14:15:19 +0200
>> Cc: Eric Blake <address@hidden>,
>> address@hidden
>>
>>> 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;
>>
>> No, you are looking at the right file, but not the right place.
>
> Sorry, you lost me here. Why isn't this the right place?
>
> I was trying to explain my comments about convert_abs_rel not testing
> that the return values from canonicalize_filename_mode are non-NULL,
> before using them. The ab ove snippet is from
> canonicalize_filename_mode, and AFAICT it clearly shows that the
> return value _can_ be NULL. So what am I missing?
Actually, I am the one who misunderstood your purpose, sorry. I was
actually answering to:
>>> +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.
this last bit: this file does use xalloc, but, as you show, it still
can return NULL.
Still, I have been asked to address many issues in relpath before
a possible integration. One issue was making it library-ready,
which I partly did by eliminating xalloc.h. But there are other
issues, including the fact that relpath relies on non-library-ready
modules.
So I am questioning the relevance of making relpath xalloc.h free,
as it makes the code more complex for no palatable advantage.
Before addressing other issues in my proposal, I would like to know
if everybody agrees that being lgpl, being xalloc/error free, etc.
is irrelevant for relpath?
- Re: new module: relpath, (continued)
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, 2012/06/18
- Re: new module: relpath, Akim Demaille, 2012/06/19
- Re: new module: relpath, Eli Zaretskii, 2012/06/19
- Re: new module: relpath,
Akim Demaille <=
- Re: new module: relpath, Eric Blake, 2012/06/22
- Re: new module: relpath, Jim Meyering, 2012/06/22