Re: new module: relpath

[Eric Blake]

On 06/14/2012 10:02 AM, Akim Demaille wrote:
> Hi all,
> 
> In Bison, I consider computing relative paths between files
> (one concrete use is when the user creates the parser implementation
> file in --output=sub1/sub2/parser.c and the header file in
> --defines=sub3/sub4/parser.h, in which case parser.c should include
> "../../sub3/sub4/parser.h").

I like the idea, but...

> +/* 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.

> +
> +  /* Get dirname to generate paths relative to.  */
> +  realtarget[dir_len (realtarget)] = '\0';
> +
> +  if (!relpath (realfrom, realtarget, relative_from, PATH_MAX))

Since limiting to PATH_MAX is a bad idea, it seems like a better
interface would be one that returns a char*, already malloc'd, of the
appropriate length, regardless of what PATH_MAX may (or may not) be.
Also, we can compute a runtime bound on the string length - if I'm
reasoning about it correctly, the output should never exceed the maximum
of the canonical target name, or of the original target name plus a
multiple of '../' patterns corresponding to the number of '/' found in
the canonical from name.

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

signature.asc
Description: OpenPGP digital signature