[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new module: relpath
From: |
Pádraig Brady |
Subject: |
Re: new module: relpath |
Date: |
Sun, 17 Jun 2012 15:26:05 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 |
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.
Re: new module: relpath, Akim Demaille, 2012/06/18
Re: new module: relpath, Eli Zaretskii, 2012/06/18