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
