Re: new module: relpath

[Akim Demaille]

Le 14 juin 2012 à 18:55, Eric Blake a écrit :

>> +/* Return FROM represented as relative to the dir of TARGET.
>> +   The result is malloced.  */
>> +
>> +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);
>> +
>> +  /* Write to a PATH_MAX buffer.  */
>> +  char *relative_from = xmalloc (PATH_MAX);
> 
> 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.