Re: new module: relpath

[Bruno Haible]

Hi Pádraig,

> >   concat-filename
> >   filename
> >   filenamecat
> > It would be good to choose a module name in this spirit.
> 
> I suppose relname would be most appropriate given that argument,
> though I think in this case it's slightly better to keep the relpath name
> so as to align with similar functions elsewhere like
> os.path.relpath() and relpath(1)?

GNU != Python, and module names are not restricted to 8 characters in length.
Why not call the module
  relative-filename
or
  filename-relative (as Akim proposes, for native French speakers)?

> > I find it odd to have a function that produces either a string or
> > some output (on a fixed stream, that is not even passed as argument).
> > For a gnulib module it would be more appropriate to have only the string
> > case. Users who need to output it to stdout can do that after invoking
> > the function.
> 
> Well there are 2 uses in coreutils at present.
> ln wants the string returned, but the realpath command
> just wants relpath() to output to stdout,
> to avoid the malloc and data copy overhead.
> If you wanted to make it a bit more general, I guess you
> could pass in the stream rather than defaulting to stdout.

If you pass the stream as argument, the use that wants a stream needs to
call open_memstream() or fmemopen(), which is not portable. Whereas if
the function returns a malloc()ed string, it can be used portably in the
other case.

Avoiding the "malloc and data overhead" sounds like an over-optimization
here. malloc() is the normal way to allocate memory for a string. There
are cases where you might want to avoid it. But here? Can you imagine an
application where it is important to relativize thousands or millions of
filenames in very short time? I can't.

Bruno