Re: new module: relpath

[Eric Blake]

On 06/18/2012 04:02 AM, Akim Demaille wrote:

>> We really shouldn't be using malloc(PATH_MAX); there are platforms like
>> Hurd where it is undefined or extremely large (coreutils caps things to
>> avoid this issue), and you are wasting memory if it is even possible to
>> allocate this much.  Furthermore, it is possible for the computed
>> relative path to be longer than PATH_MAX, but still valid (especially
>> true when we cap PATH_MAX lower than what the system really supports).
>> This is a bug in coreutils, but we should fix it as part of migrating to
>> gnulib.
> 
> Actually relpath uses realpath, and realpath features
> (canonicalize-lgpl):
> 
> #ifdef PATH_MAX
>   path_max = PATH_MAX;
> #else
>   path_max = pathconf (name, _PC_PATH_MAX);
>   if (path_max <= 0)
>     path_max = 8192;
> #endif
> 
>   if (resolved == NULL)
>     {
>       rpath = malloc (path_max);
>       if (rpath == NULL)
>         {
>           /* It's easier to set errno to ENOMEM than to rely on the
>              'malloc-posix' gnulib module.  */
>           errno = ENOMEM;
>           return NULL;
>         }
>     }
> 
> so I'm not sure fighting that limitations is worth it.

But in the context of canonicalize-lgpl, we are using path_max as an
initial allocation hint, and can allocate larger than that (that is, the
8k-constrained PATH_MAX is not an absolute limit - see the later
realloc() of rpath), whereas the interface of relpath as first proposed
IS constrained by the limit (it does not reallocate larger).  It is
still worth fixing our public interface to not have a needless
constraint; it's okay to start with a conservative guess to minimize
allocation churn in the common case, but only if you can go beyond that
guess.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature