On 06/17/2012 10:54 AM, Bruno Haible wrote: > 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)?
Cool, filename-relative sounds good > >>> 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. OK fair enough. Since there are lots of appending of strings here, the approach taken in coreutils so far was to append in a large buffer allocated up front, or just to write to stdout. I guess something in between is more appropriate for a lib. I.E. efficiently append to a string on the heap. This is a common operation, so maybe there are routines in gnulib to use for this? I previously abstracted this operation in: http://www.pixelbeat.org/libs/sbuf.h http://www.pixelbeat.org/libs/sbuf.c cheers, Pádraig.
