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 ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
