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.
