bug-gnulib
[Top][All Lists]
Advanced

[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?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]